Developing systems generally involves creating a number of different specifications. For instance, a requirements specification gives the intended effects of a system, while a design specification determines how the system will bring about those effects. Many designs might be developed and evaluated against the same requirements. A test specification then describes test procedures that check whether requirements are met by real or virtual systems built and operated according to some design.

A model is a representation in some modeling language of all or part of any of the above kinds of system specification. The semantics of such models defines what it means for real or virtual things in a modeled system to conform to the specification given by the model. KerML is a foundational modeling language for expressing various kinds of system models with consistent semantics.

Syntactically, KerML is divided into three layers, with each layer building increasingly specific constructs on the previous layer. These layers are, from general to specific:

1. The Root Layer includes the most general syntactic constructs for structuring models, such as elements, relationships, annotations, and packaging.
2. The Core Layer includes the most general constructs that have semantics based on classification.
3. The Kernel Layer provides commonly needed modeling capabilities, such as associations and behavior.

The Core Layer grounds KerML semantics by interpreting it using mathematical logic. However, additional semantics are then specified through the relationship of Kernel abstract syntax constructs to model elements in the Kernel Semantic Library, which is written in KerML itself. Models expressed in KerML thus essentially reuse elements of the Semantic Library to give them semantics. The Semantic Library models give the basic conditions for the conformance of modeled things to the model, which are then augmented in the user model as appropriate.

Having a consistent specification of semantics helps people interpret models in the same way. In particular, because the Semantic Library models are expressed in the same language as user models, engineers and tool builders can inspect the library models to formally understand what real or virtual effects are actually being specified by their models for systems being modeled. More uniform model interpretation improves communication between everyone involved in modeling, including modelers and tool builders.

The remainder of this document is organized into four major clauses.

• Clause 7 describes KerML from a user point of view, covering all the modeling constructs in the language. It is an informative reference for the normative language specification given in the following three subclauses.
• Clause 8 specifies the normative metamodel for the KerML language. This includes the complete grammar for the concrete syntax, which is a textual notation (see 8.2 ), the abstract syntax, which is a MOF model (see 8.3 ), and formal semantics (see 8.4 ).
• Clause 9 specifies the normative Kernel Model Libraries, each of which is a set of library models available to be used in all KerML user models. They include the Semantic Library, which is a set of KerML models used to provide Kernel-layer semantics to user models (see 9.2 ), the Data Type Library of standard data types (see 9.3 ) and the Function Library of functions on those data types (see 9.4 ).
• Clause 10 specifies the format for standard file-based interchange of KerML models between tools.

In addition, Annex A provides basic (non-normative) guidance on incrementally instantiating models for execution, in a way that conforms to the formal semantics as (normatively) specified in the metamodel (see 8.4 ), as supported by the Semantic Model Library (see 9.2 ).

This specification represents the work of many organizations and individuals. The Kernel Model Language concept, as developed for use with SysML v2, is based on earlier work of the KerML Working Group, which was led by:

• Conrad Bock, US National Institute of Standards and Technology (NIST)
• Charles Galey, Jet Propulsion Laboratory
• Bjorn Cole, Lockheed Martin Corporation

The primary authors of this specification document and the syntactic and library models described in it are:

• Ed Seidewitz, Model Driven Solutions
• Conrad Bock, US National Institute of Standards and Technology (NIST)
• Bjorn Cole, Lockheed Martin Corporation
• Ivan Gomes, Twingineer
• Hans Peter de Koning, DEKonsult
• Vince Molnár, Budpest University of Technology and Economics

Other contributors include:

• Manfred Koethe, 88solutions
• Karen Ryan, Siemens

The specification was formally submitted for standardization by the following organizations:

• 88solutions Corporation
• Dassault Systèmes
• GfSE e.V.
• IBM
• INCOSE
• Intercax LLC
• Lockheed Martin Corporation
• MITRE
• Model Driven Solutions, Inc.
• PTC
• Simula Research Laboratory AS
• Thematix Partners LLC

However, work on the specification was also supported by over 200 people in over 80 organizations that participated in the SysML v2 Submission Team (SST). The following individuals had leadership roles in the SST:

• Manas Bajaj, Intercax LLC (API and services development lead)
• Yves Bernard, Airbus (v1 to v2 transformation co-lead)
• Bjorn Cole, Lockheed Martin Corporation (metamodel development co-lead)
• Sanford Friedenthal, SAF Consulting (SST co-lead, requirements V&V lead)
• Charles Galey, Lockheed Martin Corporation (metamodel development co-lead)
• Karen Ryan, Siemens (metamodel development co-lead)
• Ed Seidewitz, Model Driven Solutions (SST co-lead, pilot implementation lead)
• Tim Weilkiens, oose (v1 to v2 transformation co-lead)

The specification was prepared using CATIA No Magic modeling tools and the OpenMBEE system for model publication (http://www.openmbee.org), with the invaluable support of the following individuals:

• Tyler Anderson, No Magic/Dassault Systèmes
• Christopher Delp, Jet Propulsion Laboratory
• Ivan Gomes, Twingineer
• Doris Lam, Jet Propulsion Laboratory
• Robert Karban, Jet Propulsion Laboratory
• Christopher Klotz, No Magic/Dassault Systèmes
• John Watson, Lightstreet Consulting

This clause provides an informative description of KerML. Clause 8 gives the full definition of the KerML metamodel, which is the normative specification for implementing the language. In contrast, the description in this clause focuses on how the various constructs of the language are used, along with the Kernel Model Library (see Clause 9 ), to construct models. While non-normative, it is intended to be precise and consistent with the normative specification of the language.

The following subclauses present the language features in each of the Root, Core and Kernel Layers of KerML (as described in 6.1). Each layer is then further subdivided, following a parallel structure to the packaging of the metamodel (see 8.1 ). Each subclause within a layer includes references to the corresponding concrete syntax, abstract syntax and semantics subclauses from the normative metamodel specification. In this way, the clause can be used as a general reference for KerML as well as a guide for better understanding of the formal specification of the metamodel.

This clause contains many examples of the KerML textual notation. In order to distinguish this text from normal body text, the following stylistic conventions are used in this clause.

1. Textual notation appears in "code" font. This includes references to individual element names from both example models (such as Vehicle and wheels) and the Kernel Model Library (such as Performance and performances), as well as more extensive model snippets.
2. Keywords appear in boldface, both when referenced in-line in body text ("Features are declared using the feature keyword.") and when used within complete notation examples.
3. Longer samples of textual notation are written in separate paragraphs, indented relative to body paragraphs.

The Root layer provides the most general syntactic capabilities of the language: elements and relationships between them, annotations of elements, and membership of elements in namespaces. These capabilities are the syntactic foundation for structuring models in KerML, but they do not actually represent anything about a modeled system, and so have no semantic specification. The Core and Kernel layers build on the foundation provided by Root to provide constructs with modeling semantics (see 7.3 and 7.4 ).

Metamodel references:

• Concrete syntax, 8.2.3.1
• Abstract syntax,  8.3.2.1
• Semantics, none

Elements are the constituents of a model. Some elements represent relationships between other elements, known as the related elements of the relationship. In general terms, a model is constructed as a graph structure in which relationships form the edges connecting non-relationship elements constituting the nodes. However, since relationships are themselves elements, it is also possible in KerML for a relationship to be a related element in a relationship and for there to be relationships between relationships.

One of the related elements of a relationship may be the owning related element of the relationship. If the owning related element of a relationship is deleted from a model, then the relationship is also deleted. Some of the related elements of a relationship (distinct from the owning related element, if any) may be owned related elements. If a relationship has owned related elements, then, if the relationship is deleted from a model, all its owned related elements are also deleted.

The owned relationships of an element are all those relationships for which the element is the owning related element. The owned elements of an element are all those elements that are owned related elements of the owned relationships of the element (notice the extra level of indirection through the owned relationships). The owning relationship of an element (if any) is the relationship for which the element is an owned related element (of which the element can have at most one). The owner of an element (if any) is the owning related element of the owning relationship of the element (again, notice the extra level of indirection through the owning relationship).

The deletion rules for relationships imply that, if an element is deleted from a model, then all its owned relationships are also deleted and, therefore, all its owned elements. This may result in a further cascade of deletions until all deletion rules are satisfied. An element that has no owner acts as the root element of an ownership tree structure, such that all elements and relationships in the structure are deleted if the root element is deleted. Deleting any element other than the root element results in the deletion of the entire subtree rooted in that element.

Every element has a unique identifier known as its element ID. The properties of an element can change over its lifetime, but its element ID does not change after the element is created. An element may also have additional identifiers, its alias IDs, which may be assigned for tool-specific purposes.

The KerML textual notation, however, does not have any provision for specifying element or alias IDs, since these are expected to be managed by the underlying modeling tooling. Instead, an element may also have a name and/or a short name, by which it can be referenced in the notation. While the language makes no formal distinction between names and short names, the intent is that the name of an element should be fully descriptive, particularly in the context of the definition of the element, while the short name, if given, should be an abbreviated name useful for referring to the element. (For further discussion of naming, see also 7.2.5 ).

In most cases, an element is declared using a keyword indicating the kind of element it is (e.g., classifier or feature). The declaration of an element may also specify a short name and/or name for it, in that order. The short name is distinguished by being surrounded by the delimiting characters < and >.

classifier <c123> AClassifier;
feature aFeature;

Note that it is not required to specify either a short name or a name for an element. However, unless at least one of these is given, it is not possible to reference the element from elsewhere in the textual notation.

Names and short names have the same lexical structure, which has two variants.

1. A basic name is one that can be lexically distinguished in itself from other parts of the notation. The initial character of a basic name must be a lowercase letter, an uppercase letter or an underscore. The remaining characters of a basic name can be any character allowed as an initial character or any digit. However, a reserved keyword may not be used as a name, even though it has the form of a basic name (see 8.2.2.6 for the list of reserved words).

   Vehicle
   power_line

2. An unrestricted name provides a way to represent a name that contains any character. It is represented as a non-empty sequence of characters surrounded by single quotes. The name consists of the characters within the single quotes – the single quotes are not included as part of the represented name. The characters within the single quotes may not include non-printable characters (including backspace, tab and newline). However, these characters may be included as part of the name itself through use of an escape sequence. In addition, the single quote character or the backslash character may only be included within the name by using an escape sequence.

   '+'
   'circuits in line'
   'On/Off Switch'
   'Ångström'
   

An escape sequence is a sequence of two text characters starting with a backslash as an escape character, which actually denotes only a single character (except for the newline escape sequence, which represents however many characters is necessary to represent an end of line in a specific implementation).  Table 4 in subclause  8.2.2.3 shows the meaning of the allowed escape sequences.

In addition to the declaration notated as above, the representation for an element may include a body, which is a list of owned elements delimited by curly braces {...}. It is a general principle of the KerML textual concrete syntax that the representation of owned elements are nested inside the body of the representation of the owning element. In this way, when the notation for the owning element is removed in its entirety from the representation of a model, the owned elements are also removed.

namespace P {
    // This is the body of the namespace, declaring its owned members.
    classifier A;
    classifier B {
        // This is the body of the classifier, declaring its owned features.
        feature x;
        feature y;
    }
}

The related elements of a relationship are divided into source and target elements. A relationship is said to be directed from its source elements to its target elements. It is allowed for a relationship to have only source or only target elements. However, by convention, an undirected relationship is usually represented as having only target elements.

A relationship must have at least two related elements. A relationship with exactly two related elements is known as a binary relationship. A directed binary relationship is a binary relationship in which one related element is the source and one is the target. Most specialized kinds of relationship in KerML are directed binary relationships (the principal exceptions being dependencies, associations and connectors, see 7.2.3 , 7.4.5 , and 7.4.6 ).

Various kinds of relationships are declared with special notations showing their related elements. A relationship may also have a body that specifies owned related elements of the relationship, which may include any kind of element other than an annotating element (see 7.2.4 ). If an annotating element (i.e., a comment, textual representation or metadata feature) is included in the body of a relationship, then, rather than being directly an owned related element of the containing relationship, the annotating element is an owned related element of an annotation relationship owned by the containing relationship (see 7.2.3.2 for an example).

Metamodel references:

• Concrete syntax,  8.2.3.2
• Abstract syntax,  8.3.2.2
• Semantics, none​​​

A dependency is a kind of relationship between any number of client (source) and supplier (target) elements. It implies that a change to a supplier element may result in a change to a client element. Dependencies can be useful for representing relationships between elements in an abstract way.  For example, a dependency can be used to represent that an upper layer of an architecture stack may depend on a lower layer of the stack.

A dependency is declared using the keyword dependency, optionally followed by a short name and/or name (see 7.2.2 ). The client elements of the dependency are then given as a comma-separated list of qualified names following the keyword from, followed by a similar list of the supplier elements after the keyword to. If no short name or name is given for the dependency, then the keyword from may be omitted.

dependency Use 
    from 'Application Layer' to 'Service Layer';

// 'Service Layer' is the client of this dependency, not its name.
dependency 'Service Layer' 
    to 'Data Layer', 'External Interface Layer';

A dependency declaration may also optionally have a relationship body (see  7.2.2.3 ) containing any additional owned related elements (which act as suppliers) and annotating elements owned by the dependency via annotation relationships (see 7.2.4 ).

dependency 'Service Layer' 
    to 'Data Layer', 'External Interface Layer' {
    /* 'Service Layer' is the client of this dependency, 
     * not its name. */
}

Metamodel references:

• Concrete syntax,  8.2.3.3
• Abstract syntax,  8.3.2.3
• Semantics, none​​​

An annotation is a relationship between an annotated element and an annotating element that provides additional information about the element being annotated. Any kind of element may be annotated, but only certain kinds of elements may be annotating elements. Specific kinds of annotating elements include comments and textual representations (see 7.2.4.2 and 7.2.4.3 ). A further kind of annotating element for user-defined metadata is defined in the Kernel layer (see 7.4.13 ).

Each annotation relationship is between a single annotating element and a single annotated element, but an annotating element may have multiple annotation relationships with different annotated elements, and any element may have multiple annotations. The annotated element of an annotation can optionally be the owning related element of the annotation, in which case the annotation is an owned annotation of the owning annotated element. If an annotating element is an owned member of a namespace (see 7.2.5 ) and is not involved in any annotation relationships, then its owning namespace is considered to be its annotated element without the need for an explicit annotation relationship.

A comment is an annotating element with a textual body that in some way describes its annotated element. Documentation is a kind of comment that has the special status of documenting the annotated element, known in this case as the documented element. A documentation comment is always an owned element of its documented element.

The full declaration of a comment begins with the keyword comment, optionally followed by a short name and/or name (see 7.2.2.2 ). One or more annotated elements are then identified for the comment after the keyword about, indicating that the comment has annotation relationships to each of the identified elements. The body of the comment is written lexically as regular comment text between /* and */ delimiters (see also 8.2.2.2 ).

classifier A;
classifier B;
comment Comment1 about A, B
    /* This is the comment body text. */

If the comment is an owned member of a namespace (see 7.2.5 ), then the explicit identification of annotated elements can be omitted, in which case the annotated element is implicitly the containing namespace. Further, in this case, if no short name or name is given for the comment, then the comment keyword can also be omitted.

namespace N {
    comment C /* This is a comment about N. */

    /* This is also a comment about N. */
}

A locale can also be specified for a comment, using the keyword locale followed by the locale string, placed immediately before the comment body (whether or not the comment keyword is used). The locale identifies the language of the body text and, optionally, the region and/or encoding. The format is language[_territory][.codeset][@modifier] (conformant to [ISO15897]).

comment C_US_English locale "en_US"
    /* This is US English comment text */

A documentation comment is notated similarly to a regular comment, but using the keyword doc rather than comment. The documented element of a documentation comment is always the owning element of the documentation.

dependency X from A to B {
    doc X_Comment
        /* This is a documentation comment about X. */
    doc /* This is more documentation about X. */
}
namespace P {
    doc P_Comment /* This is a documentation comment about P. */
}

The actual body text of a comment does not include the initial /* and final */ characters. Further, the written text is processed to allow formatting using * characters to delimit consistent initial indentation of a comment lines. For example, the comment notation in:

namespace CommentExample {
    /*
     * This is an example of multiline
     * comment text with typical formatting
     *     for readable display in a text editor.
     */
}

would result in the following body text in the comment element in the represented model:

This is an example of multiline
comment text with typical formatting
    for readable display in a text editor.

The body text of a comment can include markup information (such as HTML), and a tool may (but is not required to) display such text as rendered according to the markup. (See 8.2.3.3.2 for the complete rules for processing comment text.)

A textual representation is an annotating element whose textual body represents its annotated element (known in this case as the represented element) in a given language. A textual representation is notated similarly to a documentation comment (see 7.2.4.2 ), but with the keyword rep used instead of comment. As for documentation, a textual representation is always owned by its represented element. In particular, if the textual representation is an owned member of a namespace (see  7.2.5 ), the represented element is the containing Namespace. A textual representation declaration must also specify the language used for the textual body as a literal string (see 8.2.2.5 ) following the keyword language. If the textual representation has no short name or name, then the rep keyword can also be omitted.

class C {
    feature x: Real;
    inv x_constraint {
        rep inOCL language "ocl" 
        /* self.x > 0.0 */
    }
}
behavior setX(c : C, newX : Real) {
    language "alf"
        /* c.x = newX;
         * WriteLine("Set new x");
         */
}

The lexical comment text given for a textual representation is processed as for regular comment text (see 7.2.4.2 ), and it is the result after such processing that is the textual representation body expected to conform to the named language.

Note. Since the lexical form of a comment is used to specify the textual representation body, it is not possible to include comments of a similar form in the body text.

The language name in a textual representation is case insensitive. The name can be of a natural language, but will often be for a machine-parsable language. In particular, there are recognized standard language names.

If the language is  "kerml", then the body of the textual representation must be a legal representation of the represented element in the KerML textual notation. A tool can use such a textual representation to record the original KerML notation text from which an element is parsed. Other standard language names that can be used in a textual representation include "ocl" and "alf", in which case the body of the textual representation must be written in the Object Constraint Language [OCL] or the Action Language for fUML [Alf], respectively.

However, for any other language than "kerml", the KerML specification does not define how the body text is to be semantically interpreted as part of the model being represented. An element with no other definition than a textual representation in a language other than KerML is essentially a semantically "opaque" element specified in the other language. Nevertheless, a conforming KerML tool may (but is not required to) interpret such an element consistently with the specification of the named language.

Metamodel references:

• Concrete syntax,  8.2.3.4
• Abstract syntax,  8.3.2.4
• Semantics, none

A namespace is an element that contains other elements via membership relationships with those elements. The namespace is the source element and owner of the membership. The target of a membership can be any kind of element, known as the member element of the membership. If the membership is an owning membership, then the member element is known as an owned member element, which is the only owned related element of the membership.

A namespace may also import memberships from other namespaces. Further, a type, which is kind of namespace, may inherit memberships from other types that it specializes (see  7.3.2 ).

The members of a namespace are the member elements of all the memberships of the namespace (whether owned, imported or inherited). The owned members of a namespace are the owned member elements of all the owned memberships of the namespace that are owning memberships.

If an element is a member of a namespace, then any name for that element relative to the namespace is known as an unqualified name for that element in the namespace. If the containing namespace is not a root namespace (see  7.2.5.3 ), then the qualified name for the member element consists of a name for the containing namespace, known as the qualifier, followed by an unqualified name for the element. Since a namespace is an element that may itself be a member of another namespace, a qualifier may be a qualified name. Therefore, a qualified name of an element, in general, has the form of a list of unqualified names of namespaces, each relative to the previous one, followed by the unqualified name of the element in the final namespace.

A qualified name is notated as a sequence of segment names separated by "::" punctuation. An unqualified name can be considered the degenerate case of a qualified name with a single segment name. A qualified name is used in the KerML textual concrete syntax to identify an element that is being referred to in the representation of another element. A qualified name used in this way does not appear in the corresponding abstract syntax—instead, the abstract syntax representation contains an actual reference to the identified element. 

Name resolution is the process of determining the element that is identified by a qualified name (see 8.2.3.5 ). Normally, name resolution begins by searching in the local namespace containing the qualified name reference. If local name resolution is not successful, the search proceeds outwards to successive containing namespaces until a root namespace is reached (see 7.2.5.3 ), at which point a final attempt is made to search the global namespace consisting of all available root namespaces. However, if a qualified name is preceded by the global scope qualification $::, then name resolution begins in the global namespace, regardless of the location of the qualified name reference.

Since namespaces and their members may have aliases (see 7.2.5.2 ), it is possible for there to be multiple qualified names for an element even if it does not itself have aliases. On the other hand, if a namespace does not have any name, then its members will have no qualified names, even if they are themselves named.

A namespace that is not a root namespace (see 7.2.5.3 ), and does not represent any more specialized modeling construct (such as a type—see 7.3.2 ) is declared using the keyword namespace, optionally followed by a short name and/or name (see 7.2.2.2 ). The body of the namespace is notated as a list of representations of the content of the namespace delimited between curly braces {...}. If the namespace is empty, then the body may be omitted and the declaration ended instead with a semicolon.

namespace <'1.1'> N1; // This is an empty namespace.
namespace <'1.2'> N2 {
    doc /* This is an example of a namespace body. */
    class C;
    datatype D;
    feature f : C;
    namespace N3; // This is a nested namespace.
}

Declaring an element within the body of a namespace denotes that the element is an owned member of the namespace—that is, that there is an owning membership relationship between the namespace and the member element.

The visibility of the membership can be specified by placing one of the keywords public, protected or private before the public element declaration. If the membership is public (the default), then it is visible outside of the namespace. If it is private, then it is not visible. For namespaces other than types, protected visibility is equivalent to private. For types, protected visibility has a special meaning relating to member inheritance (see  7.3.2 ).

namespace N3 {
    public class C;
    private datatype D;
    feature f : C; // public by default
}

An alias for an element is a non-owning membership of the element in a namespace, which may or may not be the same namespace that owns the element. An alias name or short name is determined only relative to its membership in the namespace, and can therefore be different than the name or short name defined on the element itself. Note that the same element may be related to a namespace by multiple alias memberships, allowing the element to have multiple, different names relative to that namespace.

An alias is declared using the keyword alias followed by the alias short name and/or name, with a qualified name identifying the element given after the keyword for. The alias declaration may optionally include a body as described for relationships in 7.2.2.3 . The visibility of the alias membership can be specified as for an owned member.

namespace N4 {
    class A;
    class B;
    alias <C> CCC for B {
       doc /* Documentation of the alias. */
    }
    private alias D for B;
}

A comment (see 7.2.4.2 ), including documentation, declared within a namespace body also becomes an owned member of the namespace. If no annotated elements are specified for the comment (with an about clause), then, by default, the comment is considered to be about the containing namespace.

namespace N5 {
    class A;
    comment Comment1 about A
        /* This is a comment about class A. */

    comment Comment2
        /* This is a comment about namespace N5. */

    /* This is also a comment about namespace N5. */

    doc N9_Doc 
        /* This is documentation about namespace N5. */ 
}

With the ability to specify names, short names and aliases for elements, any element can potentially have several names relative to a namespace. However, the set of names provided for any one member of a namespace must be disjoint from the set of names provided for any other member of the namespace. That is, a namespace effectively provides a "space" of names, each one of which uniquely identifies a single member element of the namespace (though there may be multiple names that identify the same element). This is known as the distinguishibility of namespace memberships.

A root namespace is a namespace that has no owner. The owned members of a root namespace are known as top-level elements. Any element that is not a root namespace has an owner and, therefore, must be in the ownership tree of a top-level element of some root namespace.

The declaration of a root namespace is implicit and no identification of it is provided in the KerML textual notation. Instead, the body of a root namespace is given simply by the list of representations of its top-level elements.

doc /* This is a model notated in KerML concrete syntax. */
classifier A {
    feature c : C;
}
class C;
datatype D;
feature f: C;
package P;

Since the notation does not provide a means for naming a root namespace, the name of a top-level element is not qualified by the name of its containing root namespace. The name resolution rules consider all top-level elements to be directly and globally visible without qualification (see 8.2.3.5 ). Therefore, the fully qualified name of an element relative to a root namespace always begins with the name of a top-level element in the root namespace, without regard to the name (if any) of the root namespace.

A namespace may import visible memberships from other namespaces. The complete set of memberships of a namespace include all its owned memberships and all its imported memberships, and the member elements of imported memberships are included in the set of members of the namespace. Various kinds of namespaces may also define additional memberships to be included in the set of memberships of that kind of namespace (for instance, the memberships of a type also include its inherited members – see  7.3.2 ) and which of those are visible (e.g., public inherited memberships).

If the member name or member short name of any imported membership conflicts with the name of any owned member, or with the name of any visible membership from any other imported namespace, then the conflicting membership is hidden and is not included in the set of imported memberships of the importing namespace. As a result of this rule and the distinguishability rule for owned members (see 7.2.5.2 ), the names of all owned and imported members will always be distinct from each other. Any specialized kind of namespace that adds further kinds of memberships (e.g., inherited memberships of types) always maintains the property that the names of all memberships of a namespace are distinct from each other.

The namespace that is the source of an import relationship, known as the importing namespace, also owns it. There are two types of import relationships. A membership import is a relationship between the importing namespace and a single membership, which becomes an imported membership of the importing namespace. A namespace import is a relationship between the importing namespace and an imported namespace, in which all visible memberships of the imported namespace become imported memberships of the importing namespace.

A membership import is denoted using the keyword import followed by a qualified name, which identifies the imported membership (be member name or member short name). The member element of the imported membership becomes an imported member of the importing namespace. Note that the imported membership may be for an alias of the imported member (see 7.2.5.2 ), in which case the element will be known by that name in the importing namespace.

namespace N6 {
    private import N4::A;
    private import N4::C; // Imported with name "C".
    namespace M {
        import C; // "C" is re-imported from N4 into M.
    }
}

A namespace import is also denoted using the keyword import followed by a qualified name, but with the qualified name suffixed by  "::*". In this case, the qualified name identifies the imported namespace. All visible memberships of the imported namespace then become imported memberships of the importing namespace.

namespace N7 {
    // Memberships A, B and C are all imported from N4.
    private import N4::*;
}

If the declaration of either a membership or namespace import is further suffixed by "::**", then the import is recursive. Such an import is equivalent to importing memberships as described above for either an imported membership or namespace, followed by further recursively importing from each imported member that is itself a namespace, with the following limitations:

1. Recursive import only continues with a namespace that is either the imported element of an original recursive membership import or an owned member of an imported namespace.
2. Memberships inherited via implied specializations (of any kind) are not imported by recursive imports (see also  7.3.2.3 on Specialization and 8.4.2 on Semantic Constraints and Implied Relationships).

namespace N8 {
    class A;
    class B;
    namespace M {
        class C;
    }
}
namespace N9 {
    private import N8::**;
    // The above recursive import is equivalent to all
    // of the following taken together:
    //     import N8;
    //     import N8::*;
    //     import N8::M::*;
}
namespace N10 {
    private import N8::*::**;
    // The above recursive import is equivalent to all
    // of the following taken together:
    //     import N8::*;
    //     import N8::M::*;
    // (Note that N8 itself is not imported.)
}

The visibility of an import is always shown explicitly by placing the keyword private, protected, or public before the import declaration. If the import is private (which is the default in the abstract syntax), then the imported memberships become private relative to the importing namespace. A visibility of protected is the same as private, unless the importing namespace is a type, in which case the imported memberships are also visible in all specializations of the type (see also 7.3.2.3 on protected visibility). If the import is public, then all the imported memberships become public for the importing namespace. An import declaration may optionally have a body, as described for relationships in 7.2.2.3 .

namespace N11  {
    public import N4::A {
        /* The imported membership is visible outside N11. */
    }

    private import N5::* {
        doc /* None of the imported memberships are visible 
             * outside of N11. */
    }
}

If an import is owned by a root namespace (see 7.2.5.3 ), then the memberships imported by it are visible to and within all the top-level elements of the root namespace. However, an import owned by a root namespace is required to be private, so none of the imported memberships become globally visible outside of the root namespace. (This rule disallows the "re-export" of the same element from multiple different root namespaces, which would cause ambiguity that could complicate the resolution of unqualified, globally-visible names.)

An import may also be declared with one or more filter conditions. Given as model-level evaluable Boolean expressions (see  7.4.9 ), listed after the imported membership or namespace specification, each surrounded by square brackets [... ]. Such a filtered import is equivalent to importing an implicit package that then both imports the given imported membership or namespace and has all the given filter conditions. The effect is such that, for a filtered import, memberships are imported if and only if they satisfy all the given filter conditions. (While filtered imports may be used in any namespace, packages and filter conditions are actually Kernel-layer concepts, because expressions are only defined in that layer. See 7.4.14 .)

namespace N12 {
    private import Annotations::*;

    // Only import elements of NA that are annotated as Approved.
    private import NA::*[@Approved];
}

The Core layer builds on the Root layer to add the minimum constructs for modeling systems as designed, built and operated. Semantics is about how models are interpreted as giving conditions on how things should be (i.e., as a specification of a modeled system) or as a reflection of how things are (i.e, as a description of a modeled system). KerML semantics are based on classification: a model has elements that classify things in the modeled system.

A type is the most general kind of model element that classifies things (see 8.2.4.1.1 ). Classifiers are types that classify things, such as cars, people and processes being carried out, as well as how they are related by features (see  7.3.3 ). Features are also types, classifying relations between things (see 8.2.4.3.1 ). In addition to simple relations between two things, KerML allows features to classify longer chains of relations. For example, cars owned by people who live in a particular city might be required to be registered. These cars are identified by a chain of two relations, first the ownership of the car, then the residence of the owner.

KerML also supports taxonomies of classifications using specialization relationships between types. All the things classified by a specialized type are also classified by the general types it is related to via specialization relationships. This means that all the things classified by a specialized type have all the features of its general types, referred to as inheriting features from general to specific types. KerML includes several special kinds of specialization, including subclassification between classifiers, subsetting and redefinition between features, and feature typing between a feature and another type.

Metamodel references:

• Concrete syntax,  8.2.4.1
• Abstract syntax,  8.3.3.1
• Semantics,  8.4.3.2

Types classify things in a modeled system. The set of things classified by a type is the extent of the type, each member of which is an instance of the type. Everything being modeled is an instance of the type Anything from the Base library model (see 9.2.2 ). 

A type gives conditions for what things must be in or not in its extent (sufficient and necessary conditions, respectively). The simplest conditions directly identify instances that must be in or not in the extent. Other conditions can give characteristics of instances indicating they must be in or not in the extent. These conditions apply to all procedures that determine the extents of types, including logical solving, inference, and execution.

For example, a type Car could require every instance in its extent (everything it classifies) to have four wheels, which means anything that does not have four wheels is not in its extent (necessary condition). It does not mean all four wheeled things are in the extent (are cars), however. (Note that necessary conditions are usually stated as what must be true of all instances in the extent, even though they really only determine what is not.) Alternatively, Car could require all four wheeled things to be in its extent (sufficient condition). 

Types are namespaces, enabling them to have members via membership relationships to other elements identified as their members (see 7.2.5 ). These include inherited memberships, which are certain memberships from the general types of their owned specializations (see  7.3.2.3 ). The member names of all inherited memberships must be distinct from each other and from the member names of all owned memberships. A membership that would otherwise be imported is hidden by an inherited membership with the same member name, similarly to how it would be hidden by a conflicting owned membership (see 7.2.5 ).

Note. Name conflicts due to inherited memberships can be resolved by redefining them to give non-conflicting member names (see 7.3.4 ).

A type is declared using the keyword type, optionally followed by a short name and/or name. In addition, a type declaration defines either one or more owned specializations for the type (see  7.3.2.3 ) or a conjugator for the type (see  7.3.2.4 ). This may optionally be followed by the definition of one or more owned disjoinings (see  7.3.2.5 ).

type A specializes Base::Anything disjoint from B;
type C conjugates A;

A type is specified as abstract by placing the keyword abstract before the keyword type. A type that is not abstract is called a concrete type. Declaring a type to be abstract means that all instances of the type must also be instances of at least one concrete type that directly or indirectly specializes the abstract type.

abstract type A specializes Base::Anything;
type A1 specializes A;
type A2 specializes A;

The multiplicity constrains the number of instances in the extent of a type (the cardinality of the extent). A multiplicity is a feature whose values are natural numbers (extended with infinity, see 9.3.2.1 ) that are the only ones allowed for the cardinality of its featuring type (each multiplicity is the feature of exactly one Type). A type can have at most one feature that is its multiplicity. Cardinality for classifiers is the number of things it classifies. For features that are not end features (see below), cardinality is the number of values of the feature for a specific instance of its featuring types.

Note. The semantics of multiplicity is different for features that are identified as end features. End Features are used primarily in the definition of associations and connectors, and the semantics of end features is discussed in conjunction with them (see 7.4.5 and 7.4.6 , respectively).

The multiplicity of a type can be specified as a range after any identification of the Type, between square brackets [...]. (See  7.4.12  for a complete description of multiplicity ranges, including declaring named multiplicity features.)

// This Type has exactly one instance.
type Singleton[1] specializes Base::Anything;

The body of a type is specified as for a generic namespace, by listing the members between curly braces {...} (see 7.2.5.2 ). However, for types, protected members, indicated using the keyword protected instead of public or private, have special visibility rules for inheritance (see  7.3.2.3 ). A feature declared as an owned member of a type is automatically considered to be an owned feature of the type, related by a feature membership, unless its declaration is preceded by the keyword member, in which case it is related by regular membership (see 7.3.2.6 for details).

type Super specializes Base::Anything {
    private namespace N {
        type Sub specializes Super;
    }
    protected feature f : N::Sub;
    member feature f1 : Super featured by N::Sub;
}

The conditions that a type places on its instances (e.g., what feature it has) are always considered necessary. They can be indicated as sufficient by placing the keyword all after the keyword type. In this case, the type places additional sufficiency conditions on its instances corresponding to all the necessary conditions. For example, if Car requires all instances to be four-wheeled (necessary), and then is also indicated as sufficient, its extent will include all four wheeled things and no others. (See also the discussion in  7.3.2.1 .)

type all Car specializes MaterialThing {
    feature wheels[4] : Wheel;
}

Specializations are relationships between types, identified as specific and general, indicating that all instances of the specific type are instances of the general one (that is, the extent of the specific type is a subset of the extent of the general one, which might be the same set). This means instances of the specific type have all the features of the general one, referred to syntactically as inheriting features from general to specific types. A type may participate in multiple specialization relationships, both as specific and general types.

A specialization relationship is declared using the keyword specialization, optionally followed by a short name and/or a name. The qualified name of the specific type, or a feature chain (see 7.3.4.6 ) if the specific type is such a feature, is then given after the keyword subtype, followed by the qualified name of the general type, or a feature chain if the general type is such a feature, after the keyword specializes. The symbol :> can be used interchangeably with the keyword specializes. A specialization declaration can also optionally have a relationship body (see  7.2.2.3 ) for, e.g., nested annotations.

specialization Gen subtype A specializes B;
specialization subtype x :> Base::things {
    doc /* This specialization is unnamed. */
}

If no shortName or name is given, then the keyword specialization may be omitted.

subtype C specializes A;
subtype C specializes B;

The direct supertypes of a type are all the general types in specializations for which the type is the specific type, and the direct subtypes of a type are all the specific types in specializations for which the type is the general type. Indirect supertypes include, recursively, the supertypes of the direct supertypes of a type, and similarly for indirect subtypes.

Specialization relationships can form cycles, which means all types in the cycle have the same instances (same extent). However, since all types are required to specialize the base type Anything (directly or indirectly), no cycle of valid types can be entirely closed, unless it includes the type Anything.

The owned specializations of a type are those specializations that are owned relationships of the type (see  7.2.2 ), for which the type is the specific type. An owned specialization of a type is defined as part of the declaration of the type, rather than in a separate declaration, by including the qualified name or feature chain of the general type in a list after the keyword specializes (or the symbol :>).

type C specializes A, B;
type f :> Base::things;

A type inherits all visible and protected memberships of the general types of its owned specializations. Protected memberships are all owned and inherited memberships of the general type whose visibility is declared as protected (see also 7.3.2.2 on protected visibility) and all memberships imported via imports with visibility protected (see also 7.2.5.4 on import visibility). This means protected memberships are memberships that are only visible to their owning type and to (direct or indirect) specializations of it.

type A specializes Base::Anything {
    feature f; // Public by default.
    protected feature g;
    private feature h;
}
type B specializes A {
    // B inherits feature memberships for
    // f and g, but not h.
}

Conjugation is a relationship between types, identified as the original type and the conjugated type, indicating the conjugated type inherits visible and protected memberships from the original type, except the direction of input and output features is reversed (see  7.3.4.1  on features with direction). Features with direction in relative to the original type are treated as having direction out relative to the conjugated type, and vice versa for direction out treated as in. Features with no direction or direction inout in the original type are inherited without change.

A conjugation relationship is declared using the keyword conjugation, followed by a short name and/or a name. The qualified name of the conjugated type, or a feature chain (see  7.3.4.6 ) if the conjugated type is such a feature, is then given after the keyword conjugate, followed by the qualified name of the original type, or a feature chain if the original type is such a feature, after the keyword conjugates. The symbol ~ can be used interchangeably with the keyword conjugates. A conjugation declaration can also optionally have a relationship body (see  7.2.2.3 ) for, e.g., nested annotations.

type Original specializes Base::Anything {
    in feature Input; 
}
type Conjugate1 specializes Base::Anything;
type Conjugate2 specializes Base::Anything;
conjugation c1 conjugate Conjugate1 conjugates Original; 
conjugation c2 conjugate Conjugate2 ~ Original {
    doc /* This conjugation is equivalent to c1. */
}

If no short name or name is given, then the keyword conjugation may be omitted.

conjugate Conjugate1 conjugates Original;
conjugate Conjugate2 ~ Original;

An owned conjugation is an owned relationship of a type ( 7.2.2 ) that is a conjugation relationship, for which the type is the conjugated type. An owned conjugation for a type is defined as part of the declaration of the type, rather than in a separate declaration, by including the qualified name or feature chain of the original type after the keyword conjugates (or the symbol ~).

type Conjugate1 conjugates Original;
type Conjugate2 ~ Conjugate1;

A type can be the conjugated type of at most one conjugation relationship, and a conjugated type cannot be the specific type in any specialization relationship.

Types related by disjoining do not share instances (instances cannot be in more than one of the extents; the extents are disjoint). For example, a classifier for mammals is disjoint from a classifier for minerals, and a feature for people's parents is disjoint from a feature for their children.

A disjoining relationship is declared using the keyword disjoining, optionally followed by a short name and/or a name. The qualified name of the first type, or a feature chain (see  7.3.4.6 ) if the type is such a feature, is then given after the keyword disjoint, followed by the qualified name of the second type, or a feature chain, if the the type is such a feature, after the keyword from. A disjoining declaration can also optionally have a relationship body (see  7.2.2.3 ) for, e.g., nested annotations.

disjoining Disj disjoint A from B;
disjoining disjoint Mammal from Mineral;
disjoining disjoint Person::parents from Person::children {
    doc /* No Person can have a parent as a child. */
}

If no short name or name is given, then the keyword disjoining may be omitted.

disjoint A from B;
disjoint Mammal from Mineral;
disjoint Person::parents from Person::children;

An owned disjoining of a type is an owned relationship of the type (see  7.2.2 ) that is a disjoining relationship. An owned disjoining is defined as part of the declaration of the type, rather than in a separate declaration, by including the qualified name or feature chain of the disjoining type in a list after the keyword disjoint from, placed after any owned specializations.

type C specializes Anything disjoint from A, B;
type Mammal :> Animal disjoint from Mineral;

A feature membership is a relationship between a type and a feature that is a kind of owning membership that also implies type featuring (see 7.3.4.8 ). Features related to a type via feature membership are identified as owned features of the type. The owning type is one of the feature's featuring types, meaning that the feature specifies a relation between the owning type and the type of the feature.

A feature that is declared within the body of a type is normally an owned feature of that type, so it automatically has that type as a featuring type. This also applies to the bodies of classifiers (see 7.3.3 ) and features (see 7.3.4 ), since they are kinds of types. A feature may also be aliased in a type like any other Element (see  7.2.5 ), in which case it is related to the aliasing type by a regular membership relationship, not a feature membership, and, so, does not become one of the owned features of the type.

feature person[*] : Person;
classifier Person {
    // This declares an owned feature using a feature membership.
    feature age[1] : ScalarValues::Integer; 

    // This is not a feature membership.
    alias personAlias for person;       
}

However, if a feature declaration in the body of type is preceded by the keyword member, then the feature is owned by the containing type via a membership relationship, not a feature membership. In this case, the feature is not an owned feature of the containing type, and it does not automatically have the containing type as a featuring type, though it may have featuring types declared in its featured by list (see 7.3.4.1 on declaring the owned typings of a feature).

classifier A;
classifier B {
    // Feature f has B as its featuring type.
    feature f;

    // Feature g has A as its featuring type, not B.
    member feature g featured by A;
}

Unioning, intersecting, and differencing are relationships between an owning type and a set of other types.

1. Unioning specifies that the owning type classifies everything that is classified by any of the unioned types.
2. Intersecting specifies that the owning type classifies everything that is classified by all of the intersecting types.
3. Differencing specifies that the owning type classifies everything that is classified by the first of the differenced types but not by any of the remaining types.

Since these relationships are always owned by the source type, they are defined as part of the declaration of that type, using the keywords unions, intersects, and differences, respectively, followed by a list of qualified names (or feature chains, if appropriate, see  7.3.4.6 ) of the related types. These relationship clauses are placed after any owned specializations (see 7.3.2.3 ) but may otherwise appear in any order with each other and with any disjoining clause (see 7.3.2.5 ).

classifier Adult;
classifier Child;

classifier Person unions Adult, Child {
    feature dependents : Child[*];
    feature offspring : Person[*];
    feature grownOffspring : Adult[*] :> offspring;
    feature dependentOffspring : Child[*] :> dependents, offspring
        differences offspring, grownOffspring
        intersects dependents, offspring;
}

Multiple relationships of each kind can be specified using multiple clauses in a single declaration. In the case of differencing, any additional differences clauses after the first one mean that the owning type does not classify anything classified by any of the related types. It is not allowable, though, for a type to have just one of any of these relationships over all.

// This is valid.
classifier Person unions Adult unions Child;

// This is NOT valid.
classifier Person unions Adult;

Metamodel references:

• Concrete syntax,  8.2.4.2
• Abstract syntax,  8.3.3.2
• Semantics,  8.4.3.3

Classifiers are types that classify things in the modeled system, as distinct from features, which model the relations between them (see  7.3.4 ). Subclassification is a kind of specialization that specifically relates classifiers.

The notation for a classifier is the same as the generic notation for a type (see 7.3.2.2 ), except using the keyword classifier rather than type. However, any general types referenced in a specializes list must be Classifiers, and the specializations defined are specifically subclassifications (see  7.3.3.3 ). A classifier is also not required to have any owned subclassifications explicitly specified. If no explicit subclassification is given for a classifier, and the classifier is not conjugated, then the classifier is given a default subclassification to the most general base classifier Anything from the Base library model (see 9.2.2 ).

classifier Person { // Default superclassifier is Base::Anything.
    feature age : ScalarValues::Integer;
}
classifier Child specializes Person;

The declaration of a classifier may also specify that the classifier is a conjugated type (see 7.3.2.4 ), in which case the original type must also be a classifier.

classifier FuelInPort {
    in feature fuelFlow : Fuel;
}
classifier FuelOutPort conjugates FuelInPort;

A subclassification relationship is declared using the keyword specialization, optionally followed by a short name and/or a name. The qualified name of the subclassifier is then given after the keyword subclassifier, followed by the qualified name of the superclassifier after the keyword specializes. The symbol :> can be used interchangeably with the keyword specializes. A subclassification declaration can also optionally have a relationship body (see  7.2.2.3 ) for, e.g., nested annotations.

specialization Super subclassifier A specializes B;
specialization subclassifier B :> A {
    /* This subclassification is unnamed. */
}

If no short name or name is given, then the keyword specialization may be omitted.

subclassifier C specializes A;
subclassifier C specializes B;

An owned subclassification of a classifier is defined as part of the declaration of the classifier, rather than in a separate declaration, by including the qualified name of the superclassifier in a list after the keyword specializes (or the symbol :>).

classifier C specializes A, B;

Metamodel references:

• Concrete syntax,  8.2.4.3
• Abstract syntax,  8.3.3.3
• Semantics,  8.4.3.4

Features are types that classify how things in a modeled system are related, including by chains of relations. Relations between things can also be treated as things, allowing relations between relations, recurring as many times as needed. A feature relates instances in the intersection of the extents of its featuring types (the domain) with instances in the intersection of the extents of its featured types (the co-domain). Instances in the domain of a feature are said to "have values" that are instances of the co-domain. The domain of features with no explicit featuring types is the type Anything from the Base library model (see 9.2.2 ).

Type featuring is a relationship between a feature and a type that identifies the type as a featuring type of the feature. Feature membership is a kind of owning membership that also implies type featuring, by which a type owns a feature and becomes a featuring type of that feature (see  7.3.2.6 ).

There are also several forms of specialization that apply specifically to features.

• Feature typing is a relationship between a feature and a type that identifies the type as a featured type of the feature. 
• Subsetting is a relationship between a specific feature (the subsetting feature) and a more general feature (the subsetted feature), where the specific feature may further constrain the featuring types, featured types and multiplicity of the general feature. 
• Redefinition is a kind of subsetting in which the specific feature (the redefining feature) also replaces an otherwise inherited general feature (the redefined feature) in the context of the owning type of the specific feature.

The notation for a feature is similar to the generic notation for a type (see 7.3.2.2 ), except using the keyword feature rather than type. Further, a feature can have any of three kinds of specialization, each identified by a specific keyword or equivalent symbol:

• typed by or : – Specifies FeatureTyping (see 7.3.4.3 ).
• subsets or :> – Specifies Subsetting (see 7.3.4.4 ).
• redefines or :>> – Specifies Redefinition (see 7.3.4.5 ).

In general, clauses for the different kinds of Specialization can appear in any order in a Feature declaration.

feature x typed by A, B subsets f redefines g;

// Equivalent declaration:
feature x redefines g typed by A subsets f typed by B;

If no subsetting (or redefinition) is explicitly specified for a feature, and the feature is not conjugated, then the feature is given a default subsetting of the most general base feature things from the Base library model (see 9.2.2 ). This is true even if a feature typing is given for the feature.

abstract feature person : Person; // Default subsets Base::things.
feature child subsets person;

The declaration of a feature may also specify that the feature is a conjugated type (see 7.3.2.4 ), in which case the original type must also be a feature. In this case, the feature must not have any owned specializations.

classifier Tanks {
    feature fuelInPort {
        in feature fuelFlow : Fuel;
    }
    feature fuelOutPort ~ fuelInPort;
}

As for any type, the multiplicity of a feature can be given in square brackets [...] after any identification of the feature (see also  7.3.2.2 ). However,  the multiplicity for a feature can also be placed after one of the specialization clauses in the feature declaration, but, in all cases, only one multiplicity may be specified. In particular, this allows a notation style for multiplicity consistent with that used in previous modeling languages (such as [UML]). It is also useful when redefining a Feature without giving an explicit name (see 7.3.4.5 ).

feature parent[2] : Person;
feature mother : Person[1] :> parent;
feature redefines children[0];

In addition to, or instead of, an explicit multiplicity, a feature declaration can include either or both of the following keywords (in either order). The properties flagged by these keywords are only meaningful if the feature has a multiplicity upper bound greater than one.

• nonunique – If a feature is non-unique, then, for any domain instance, the same co-domain instance may appear more than once as a value of the feature. The default is that the feature is unique. 
• ordered – If a feature is ordered, then for any domain instance, the values of the feature can be placed in order, indexed from 1 to the number of values. The default is that the feature is unordered.

feature sensorReadings : ScalarValues::Real [*] nonunique ordered;

There are four other kinds of relationships that can be declared as owned relationships of a feature, each indicated by a specific keyword:

• disjoint from – Specifies disjoining (see 7.3.2.5 ).
• chains – Specifies feature chaining (see 7.3.4.6 ).
• inverse of – Specifies feature inverting (see 7.3.4.7 ).
• featured by – Specifies type featuring (see 7.3.4.7 ).

The clauses for these relationships must appear after any specialization or conjugation part, but can otherwise appear in any order.

feature cousins : Person[*] chains parents.siblings.children featured by Person;
feature children : Person[*] featured by Person inverse of parents;

There are a number of additional properties of a feature that can be flagged by adding specific keywords to its declaration. If present, these are always specified in the following order, before the keyword feature:

1. in, out, inout – Specifies the direction of a feature, which determines what is allowed to change its values on instances of its domain:
   • in – Things "outside" the instance. These features identify things input to an instance.
   • out – The instance itself or things "inside" it. These features identify things output by an instance.
   • inout – Both things "outside" and "inside" the instance. These features identify things that are both input to and output by an instance.
2.  derived – Specifies that the feature is derived. Such a feature is typically expected to have a bound feature value expression that completely determines its value at all times (see  7.4.11  on feature values, which is a kernel concept).
3. abstract – Specifies that the feature is abstract (see  7.3.2.2  on abstract types in general).
4. composite or portion – Specifies that the feature is either a composite or portion feature (specifying both is not allowed).
   • Values of a composite feature, on each instance of the feature's domain, cannot exist after the featuring instance ceases to exist. This only applies to values at the time the instance goes out of existence, not to other things in the co-domain that might have been values before that. Values of a composite feature also cannot be values of another composite feature that is not on the same instance of the feature's domain. Values of a composite feature also cannot be values of another composite feature that is not on the same instance of the feature's domain.
   • Portions are features whose values cannot exist without the whole, because they are the “same thing” as the whole. (For example, the portion of a person's life when they are a child cannot be added or removed from that person's life.)
5. var or const – Specifies that the feature is variable or constant (specifying both is not allowed). Portions cannot be variable or constant.
   • Values of a variable feature may vary in time over the duration of a featuring instance.
   • A constant feature is one that is potentially variable but has been constrained to have the same values over the entire duration of a featuring instance. (This is useful, for example, to redefine a variable feature to be constant over some temporal portion of a featuring instance.)

(Note that the semantics of composite, portion, var and const require a model of things existing in time, which is provided in the Kernel layer, see 7.4.3 . See also the discussion of end features in 7.4.5 .)

abstract classifier Account {
    abstract feature ntries : Entry[*] ordered;
    derived feature balance = sum(entries.amount);
}

classifier Tank specializes Object {
    in var feature fuelFlow: Fuel; 
    var feature fuel : Fuel {
        portion feature fuelPortion : Fuel;
    }
}

A feature typing relationship is declared using the keyword specialization, optionally followed by a short name and/or a name. The qualified name of the typed feature is then given after the keyword typing, followed by the qualified name of the type, or a feature chain (see  7.3.4.6 ), after the keyword typed by. The symbol : can be used interchangeably with the keyword typed by. A feature typing declaration can also optionally have a relationship body (see  7.2.2.3 ) for, e.g., nested annotations.

specialization t1 typing customer typed by Person;
specialization t2 typing employer : Organization {
    doc /* An employer is an Organization. */
}

If no short name or name is given, then the keyword specialization may be omitted.

typing customer typed by Person;
typing employer : Organization;

An owned feature typing is a feature typing that is an owned relationship of its type feature. An owned  feature typing is defined as part of the declaration of the typed feature, rather than in a separate declaration, by including the qualified name or feature chain for the type in a list after the keyword typed by (or the symbol :).

feature foodItem typed by Food, InventoryItem;

Subsetting is a kind of specialization between two features. This means that the values of the subsetting feature are also values of the subsetted feature on each instance (separately) of the domain of the subsetting feature.

A subsetting relationship is declared using the keyword specialization, optionally followed by a short name and/or a name. The qualified name of the subsetting feature, or a feature chain (see 7.3.4.6 ), is then given after the keyword subset, followed by the qualified name of the subsetted feature, or a feature chain, after the keyword subsets. The symbol :> can be used interchangeably with the keyword subsets. A subsetting declaration can also optionally have a relationship body (see  7.2.2.3 ) for, e.g., nested annotations.

specialization Sub subset parent subsets person;
specialization subset mother subsets parent {
    doc /* All mothers are parents. */
}

If no short name or name is given, then the keyword specialization may be omitted.

subset rearWheels subsets wheels;
subset rearWheels subsets driveWheels;

An owned subsetting is a subsetting that is an owned relationship of the subsetting feature. An owned subsetting is defined as part of the declaration of the subsetting feature, rather than in a separate declaration, by including the qualified name or feature chain of the subsetted feature in a list after the keyword subsets (or the symbol :>).

feature rearWheels subsets wheels, driveWheels;

A subsetting feature can restrict aspects of the subsetted feature, otherwise it will, by default, have the same properties as the subsetted feature. In particular, a subsetting feature can constrain its featured types to be specializations of those of the subsetted feature and add additional feature types. A subsetting feature can also restrict the multiplicity of its subsetted feature to allow cardinalities that are smaller than those of the subsetted feature (e.g., by specifying smaller lower and/or upper bounds).

classifier Wheel;
classifier DriveWheel specializes Wheel;
feature anyWheels[*] : Wheel;

classifier Automobile {
    // Restricts multiplicity
    composite feature wheels[4] subsets anyWheels;
    // Restricts multiplicity and type.
    composite feature driveWheels[2] : DriveWheel subsets wheels;
}

If a subsetted feature is ordered, then the subsetting feature must also be ordered. If the subsetted feature is unordered, then the subsetting feature will be unordered by default, unless explicitly flagged as ordered.

classifier Automobile {
    composite feature wheels[4] ordered subsets anyWheels;
    // driveWheels must be ordered because wheels is ordered.
    composite feature driveWheels[2] ordered : DriveWheel subsets wheels;
}

If a subsetted feature is unique, then the subsetting feature must not be specified as non-unique. If the subsetted feature is non-unique, then the subsetting feature will still be unique by default, unless specifically flagged as nonunique.

feature urls[*] nonunique : URL;
classifier Server {
    feature accessibleURLs subsets urls; // Unique by default.
    feature visibleURLs subsets accessibleURLs; // Cannot be nonunique.
}

Redefinition is a kind of subsetting that requires the values of the redefining feature and the redefined feature to be the same on each instance (separately) of the domain of the redefining feature. This means any restrictions on the values of the redefining feature relative to the redefined feature, such as typing or multiplicity, also apply to the values of the redefined feature, and vice versa.

A redefinition relationship is declared using the keyword specialization, optionally followed by a short name and/or a name. The qualified name of the redefining feature, or a feature chain (see 7.3.4.6 ), is then given after the keyword redefinition, followed by the qualified name of the redefined feature, or a feature chain, after the keyword redefines. The symbol :>> can be used interchangeably with the keyword redefines. A redefinition declaration can also optionally have a relationship body (see  7.2.2.3 ) for, e.g., nested annotations.

specialization Redef redefinition LegalRecord::guardian redefines parent;
specialization redefinition Vehicle::vin redefines RegisteredAsset::identifier {
    doc /* A "vin" is a Vehicle Identification Number. */
}

If no short name or name is given, then the keyword specialization may be omitted.

redefinition Vehicle::vin redefines RegisteredAsset::identifier;
redefinition Vehicle::vin redefines legalIdentification; 

A feature can only be redefined once for any featuring type. A feature without any feature types is considered to be implicitly featured by the most general base type Anything (see 7.3.4.1 ). It is therefore allowable to redefine such a feature by a redefining feature that does have some other featuring type. It is, however, illegal for one such feature to redefine another, because that would correspond to a semantically inconsistent redefinition of one feature of Anything by another.

The restrictions on the specification of the multiplicity, ordering and uniqueness of a subsetting feature (see 7.3.4.4 ) also apply to a redefining feature. In addition, the multiplicity of a redefining feature must only allow cardinalities that are consistent with the multiplicity of the redefined feature (e.g., it cannot have a multiplicity lower bound that is less than that of the redefined feature).

An owned redefinition is a redefinition that is an owned relationship of its redefining feature. An owned redefinition of a feature is defined as part of the declaration of the feature, rather than in a separate declaration, by including the qualified name or feature chain of the redefined feature in a list after the keyword redefines (or the symbol :>>).

feature vin redefines RegisteredAsset::identifier, legalIdentification;

If a redefining feature is declared as an owned feature of a type (see  7.3.2.6 ), then each of the redefined features of its owned redefinitions must be features that would otherwise be inherited from supertypes of its owning type. When redefined, however, these otherwise inheritable features are not inherited and are, instead, replaced by the redefining feature. This enables the redefining feature to have the same name as a redefined feature, if desired. (Note, however, that even though a redefined feature is not in the namespace of the owning type of the redefining feature, the redefined feature still has values on instances of that type, particularly when they are considered as instances of the supertype that owns the redefined feature. The values will be the same as for the redefining feature, as described above.)

In general, the resolution of a qualified name begins with the namespace in which the name appears and proceeds outwards from there to containing namespaces (see  8.2.3.5 ). However, the resolution of the qualified names of redefined features of owned redefinitions follow special rules. In particular, the local namespace of the owning type of the redefining feature is not included in the name resolution of the redefined features, with resolution beginning instead with the direct supertypes of the owning type. Since redefined features are not inherited, they would not be included in the local namespace of the owning type and, therefore, could not be referenced by an unqualified name. The special rules for redefined features, however, allow such a reference, because the name resolution begins with the namespaces of the supertypes of the owning type, one of which must contain the redefined feature.

classifier RegisteredAsset {
    feature identifier : Identifier;
}
classifier Vehicle : RegisteredAsset { // Owning type.
    // Legal even though "identifier" is not inherited.
    feature vin redefines identifier;
}

If neither a name nor a short name is given in the declaration of a feature with an owned redefinition, then the feature is implicitly given the same name and short name as the first redefined feature (which may itself have implicit names, if the redefined feature is itself a redefining feature). These implicit names are used in name resolution, just as explicitly declared names would be. This is useful when declaring a feature that redefines another feature in order to constrain it, while maintaining the same naming.

classifier WheeledVehicle {
    // The declared name is "wheels".
    composite feature wheels[1..*] : Wheel;
}
classifier MotorizedVehicle specializes WheeledVehicle {
    // The effective name is "wheels", the same name as
    // WheeledVehicle::wheels, which is being redefined.
    composite feature redefines wheels[2..4];
}
classifier Automobile specializes MotorizedVehicle {
    // The effecive name is "wheels", the same (effective) name
    // as "MotorizedVehicle::wheels", which is being redefined.
    composite feature redefines wheels[4] : AutomobileWheel;
}

Feature chaining is an owned relationship between the owning chained feature and a chaining feature. If a feature has any chaining features, then it must have at least two. The list of chaining features of a chained feature is called its feature chain.

The meaning of a chained feature depends on its feature chain. The values of a chained feature are the same as the values of the last feature in the chain. These can be found by starting with the values of the first feature (for each instance of the chained feature's domain), then on each of those, finding the values of the second feature in the chain, and so on, to values of the last feature. If a chained feature is ordered, any ordering of values earlier in the chain are imposed on values found later in the chain. If a chained feature is non-unique, duplicate values found in the last feature of the chain (which might be due to multiple values of the earlier features) are preserved in the chained feature, otherwise the last feature can have no duplicates.

A feature chain is notated as a sequence of two or more qualified names separated by dot (.) symbols. Each qualified name in a feature chain must resolve to a feature. The first qualified name in a feature chain is resolved in the local namespace as usual (see 8.2.3.5 ). Subsequent qualified names are then resolved using the previously resolved feature as the context namespace (but considering only visible memberships). This notation specifies a list of chaining features, as given by the resolution of the qualified names in the chain, in order.

The feature chain notation can be placed after the keyword chains in the declaration of the Feature, appearing after any specialization or conjugation part, but before any disjoining or type featuring part (see also 7.3.4.2 ).

feature cousins chains parents.siblings.children;

The featuring types of the chaining feature are implicitly considered to include the featuring types of the first chaining feature. Similarly, the featured types of the chaining feature are implicitly considered to include the featured types of the last chaining feature.

The feature chain notation may also be used to specify a related element in the declaration of any of the following relationships:

1. Specialization (see 7.3.2.3 )
2. Conugation (see 7.3.2.4 )
3. Unioning, intersecting and differencing (see 7.3.2.7 )
4. Disjoining (see 7.3.2.5 )
5. Subsetting (see 7.3.4.4 )
6. Redefinition (see 7.3.4.5 )
7. Feature inverting (see 7.3.4.7 )
8. Connector (see 7.4.6 , in the Kernel layer)

In this case, the related element specified using the feature chain notation becomes an owned related feature of the relationship with the feature chain as notated.

feature uncles subsets parents.siblings;
feature cousins redefines parents.siblings.children;
connector vehicle.wheelAssembly.wheels to vehicle.road;

Note. A similar dot notation is also used for the related Kernel-layer concept of a feature chain expression (see 7.4.9.3 ). However, it is always syntactically unambiguous as to whether the notation should be parsed as a plain feature chain or as a feature chain expression.

Feature inverting is a relationship between two features whose interpretations as relations are the inverse of each other. For example, a feature identifying each person's parents is the inverse of a feature identifying each person's children. A person identified as a parent of another will identify that other as one of their children.

A feature inverting relationship is declared using the keyword inverting, optionally followed by a short name and/or a name. The qualified name of the first feature, or a feature chain (see 7.3.4.6 ), is then given after the keyword inverse, followed by the qualified name of the second feature, or a feature chain, after the keyword of. A feature inverting declaration can also optionally have a relationship body (see  7.2.2.3 ) for, e.g., nested annotations.

inverting parent_child inverse Person::parent of Person::child {
    doc /* A Person is the parent of their children. */
}

If no short name or name is given, then the keyword inverting may be omitted.

inverse Person::parents of Person::children;

An owned feature inverting is a feature inverting that is an owned relationship of its first feature. An owned feature inverting is defined as part of the declaration of the inverted feature, rather than in a separate declaration, by giving the qualified name or feature chain of the other feature after the keyword inverse of.

classifier Person {
    feature children : Person[*];
    feature parents : Person[*] inverse of children;
}

Note that only a single feature identification is allowed after inverse of. While it is possible to declare multiple feature inverting relationships for a single feature, this is generally not useful.

Inverse features can be arbitrarily nested. However, while it is allowable to use feature chains in the declaration of a feature inverting relationship, note that a feature chain is a separate feature from any of the features it chains. In order to indicate that two declared features are inverses, one should use qualified names rather than feature chains.

classifier A {
    feature b1: B {
        feature c1: C;
    }
}
classifier C {
    feature b2: B {
        feature a2: A inverse of A::b1::c1;
    }
}

Type featuring is a relationship between a feature and a type, identifying the type as a featuring type of the feature (see also  7.3.4.1 ). Feature membership is a kind of type featuring that also makes the feature an owned member of the featuring type (see  7.3.2.6 ).

A type featuring relationship is declared using the keyword featuring, optionally followed by a short name and/or a name, and the keyword of. The qualified name of the featured feature is then given, followed by the qualified name of the featuring type after the keyword featured by. A type featuring declaration can also optionally have a relationship body (see  7.2.2.3 ) for, e.g., nested annotations.

featuring engine_by_Vehicle of engine featured by Vehicle;
featuring power featured by engine {
    doc /* The engine of a Vehicle has power. */ 
}

An owned type featuring is a type featuring that is an owned relationship of the featured feature. An owned type featuring is defined as part of the declaration of the feature, rather than in a separate declaration, by including the qualified name of the featuring type in a list after the keyword featured by.

classifier Vehicle;
classifier PoweredComponent;
feature engine : Engine featured by Vehicle, PoweredComponent;

Note that the domain of a feature is given by the intersection of its featuring types. That is, in the above example, an instance in the domain of engine must be both a Vehicle and a PoweredComponent.

The Kernel layer completes KerML. It extends the Core layer to add modeling capabilities beyond basic classification. These include specialized classifiers for things that have the semantics of data values (data types) from others that have an independent existence over time and space (classes), and for reified relationships between things (associations).

Classes have instances that exist or happen in time and space. They are divided into those for structure and behavior. Structures typically limit how things and relations between them might change over time, while behaviors specify changes within those limits. Structures and behaviors do not overlap, but structures can be involved in, perform, and own behaviors. Behaviors can coordinate other behaviors via steps (usages of behaviors). Functions are behaviors that yield a single result, which can be used to form trees of expressions. Interactions combine behaviors and associations. Some associations are also structures.

The Kernel layer adds semantics beyond the Core primarily by specifying how model elements use the Kernel model library (see  Clause 9 ), rather than be specified mathematically as in the Core. The Kernel textual syntax introduces keywords that translate to patterns of using Core abstract syntax and library models, acting as syntactic "markers" for modeling patterns tying Kernel to the Core. In the simplest case, this involves introducing implicit specializations of model library types. For example, classes must directly or indirectly subclassify the library class Occurrence, while behaviors must directly or indirectly subclassify the library class Performance. Sometimes more complicated reuse patterns are needed. For example, binary associations (with exactly two ends) specialize BinaryLink from the library, and additionally require the ends of the association to redefine the source and target ends of BinaryLink.

This is also how other modeling languages can be built on KerML. Domain-specific metamodels and libraries can also reuse Kernel metamodel and libraries, inheriting the patterns of library reuse above, as well as the mathematical semantics they inherit from Core. This enables domain-specific modelers to use terms and syntax familiar to them and still benefit from automated assistance based on mathematically-defined semantics.

Metamodel references:

• Concrete syntax,  8.2.5.1
• Abstract syntax,  8.3.4.1
• Semantics,  8.4.4.2

Data types are classifiers that classify data values (see 9.2.2.2.2 ). Certain primitive data types have specified extents of values, such as the numerical and other types from the ScalarValues library model (see 9.3.2 ). Other data types have features whose values can distinguish one instance of the data type from another. But, otherwise, different data values are not distinguishable.

This means that data types cannot also be classes or associations, or share instances with them. It also means that data types classify things that do not exist in time or space, because they require changing relations to other things. The feature values of a data value cannot change over time, because different feature values would inherently identify a different data value.

A data type is declared as a classifier (see 7.3.3 ), using the keyword datatype. If no owned superclassing is explicitly given for the data type, then it is implicitly given a default superclassing to the data type DataValue from the Base library model (see 9.2.2 ).

If any of the types of a feature are data types, then none of its types can be classes or associations, because classes and associations are disjoint from data types (see 8.4.4.2 ). If a feature has data types as its types, and no owned subsetting or owned redefinition is explicitly given in the feature declaration, then the feature is implicitly given a default subsetting to the Feature dataValues from the Base model library (see 9.2.2 ).

datatype IdNumber specializes ScalarValues::Integer;
datatype Reading { // Subtypes Base::DataValue by default
    feature sensorId : IdNumber; // Subsets Base::dataValues by default.
    feature value : ScalarValues::Real;
}

Metamodel references:

• Concrete syntax,  8.2.5.2
• Abstract syntax,  8.3.4.2
• Semantics,  8.4.4.3

Classes are classifiers that classify occurrences, which exist in time and space (see 9.2.4 ). Relations between an occurrence and other things can change over time and space, while the occurrence still maintains an independent identity.

A class is declared as a classifier (see 7.3.3 ), using the keyword class. If no owned superclassing is explicitly given for the class, then it is implicitly given a default superclassing to the class Occurrence from the Occurrences model library (see 9.2.4 ).

If any of the types of a feature are classes, then none of its types can be data types, because data types are disjoint from classes (see 8.4.4.3 ). If a feature has class types, and no owned subsetting or owned redefinition is explicitly given in the feature declaration, then the feature is implicitly given a default subsetting to the feature occurrences from the Occurrences library model (see 9.2.4 ), unless at least one of the types is an association structure, in which case the default subclassing is as described in 7.4.5 .

Some or all of the features of a class may be specified as variable features using the keyword var (see also 7.3.4.2 ). A variable feature is one whose values may vary over the lifetime of its featuring occurrence. A variable feature may subset a non-variable feature or a variable feature, but a non-variable feature may not subset a variable feature.

class Situation { // Specializes Occurrences::Occurrence by default.
    feature kind : SituationCode;
    var feature condition : ConditionCode;
    var feature alarmSounding : ScalarValues::Boolean;
}
class SituationStatusMonitor specializes StatusMonitor {
    // Subsets Occurrences::occurrences by default.
    abstract feature lifetimeSituations : Situation[*];
    var feature currentSituation : Situation subsets lifetimeSituations;
}

Alternatively, a features may be specified as a constant feature using the keyword const (see also 7.3.4.2 ). A constant feature is a potentially variable feature which has nevertheless been constrained to have unchanging values, perhaps within some limited context. A constant feature may subset any constant, variable or non-variable feature, but any subsetting feature of a constant feature must also be constant.

class ControlledSituation specializes Situation {
    var feature underControl : ScalarValues::Boolean;
    portion controlPeriods[*] subsets timeSlices {
        const feature redefines underControl = true;
        const feature redefines condition;
    }
}

Metamodel references:

• Concrete syntax,  8.2.5.3
• Abstract syntax,  8.3.4.3
• Semantics,  8.4.4.4

Structures are classes that classify objects, which are kinds of occurrences. Structures typically limit how their instances and relations between them can change over time, as opposed to Behaviors, which indicate how objects and their relations change. Structures and behaviors do not overlap, but structures can own behaviors, and the objects they classify can be involved in and perform behaviors.

A structure is declared as a classifier (see 7.3.3 ), using the keyword struct. If no owned superclassing is explicitly given for the structure, then it is implicitly given a default superclassing to the structure Object from the Objects library model (see 9.2.5 ).

If any of the types of a feature are structures, then all of them must be. If a feature has structure types, and no owned subsetting or owned redefinition is explicitly given in the feature declaration, then the feature is implicitly given a default subsetting to the feature objects from the Objects library model (see 9.2.5 ), unless at least one of the types is an association structure, in which case the default subsetting shall be as specified in 7.4.5 .

struct Sensor { // Specializes Objects::Object by default.
    feature id : IdNumber;
    var feature currentReading : ScalarValues::Real;
    step updateReading { ... } // Performed behavior
}
struct SensorAssembly specializes Assembly {
    composite var feature sensors[*] : Sensor; // Subsets Objects::objects by default.
}

 Metamodel references:

• Concrete syntax,  8.2.5.4
• Abstract syntax,  8.3.4.4
• Semantics,  8.4.4.5

Associations are classifiers that classify links between things (see 9.2.3.1 ). Unless the association is abstract, at least two of its features must be association ends, which identify the things being linked by (at the "ends" of) each link (exactly one thing per end, which might be the same thing). Associations with exactly two association ends are called binary associations. The end features of an association identify the participants in the links that are instances of the association and must have multiplicity 1..1. Associations can also have features that are not end features, which characterize each instance of the association separately from the things it links.

An association is also a relationship between the types of its association ends, called its related types (which need not be unique). Links are between instances of an association's related types. For binary associations, the two related types are identified as the source type and the target type (which may be the same). For associations with more than two association ends ("n-ary"), the first related type is the source type and all the remaining related types are target types.

An association is declared as a classifier (see 7.3.3 ), using the keyword assoc. Association ends are declared as features (see 7.3.4.2 ), prefixed by the keyword end. If no owned superclassification is explicitly given for the association, then it is implicitly given a default superclassification to either the association BinaryLink (if it is a binary association) or the association Link (otherwise), both of which are from the Links library model (see 9.2.3 ).

assoc Ownership { // Specializes Links::BinaryLink by default.
    end feature owner[1] : LegalEntity; // Redefines BinaryLink::source.
    end feature ownedAsset[1] : Asset;  // Redefines BinaryLink::target.
    feature valuationOnPurchase : MonetaryValue;
}

The keyword feature may also be omitted from an association end declaration (unless it has an owned cross feature, as described later).

assoc Ownership {
    end owner[1] : LegalEntity;
    end ownedAsset[1] : Asset;
    feature valuationOnPurchase : MonetaryValue;
}

Note. For a binary association, the source and target ends are already declared to have multiplicity 1..1, so this does not need to be redeclared in redefinitions of these features. However, for non-binary associations, the end multiplicity must be explicitly declared as 1..1 to override the usual default of 0..*.

For a binary association, one or both association ends can be explicitly declared to subset a cross feature owned by the other related type. This is done with cross subsetting, which is a special kind of subsetting relationship specified using the keyword crosses or the symbol =>. Only end features may have cross subsetting relationships, and an end feature can have at most one owned cross subsetting.

classifier LegalEntity {
    feature assetsOwned [*] ordered : Asset;
}
classifier Asset {
    feature owningEntities [1..*] : LegalEntity;
}
assoc AssetOwnership {
    end feature owner : LegalEntity crosses ownedAsset.owningEntities;
    end feature ownedAsset : Asset => owner.assetsOwned;
    feature valuationOnPurchase : MonetaryValue;
}

This specifies that each instance of the AssetOwnership association must link a value of the owningEntities feature of the ownedAsset with a value of the assetsOwned feature of the owner. That is, creating a AssetOwnership link between a LegalEntity and an Asset means that the Asset must be one of the assetsOwned by the LegalEntity and that the LegalEntity must be one of the owningEntities of the Asset. As shown above, the target of a cross subsetting relationship must be a feature chain (see 7.3.4.6 ) in which the first feature is the other association end and the second feature is the cross feature for that end.

Cross feature multiplicity effectively constrains the number of instances of an association. It applies to each set of instances (links) of the association that have the same (single) values for each of the other ends. For a binary association, this is the same as the number of values resulting from "navigating" across the association from an instance of one related type to instances of the other related type. Cross feature uniqueness and ordering apply to the instances navigated to, preventing duplication among them and ordering them to form a sequence.

For example, given a specific Asset, navigating across all AssetOwnership links with that Asset as the ownedAsset to the corresponding owner gives a collection of LegalEntities that must be the same as the owningEntities of the Asset. The owningEntities feature has a multiplicity lower bound of 1, requiring that there must be at least one AssetOwnership link for every Asset. Similarly, given a specific LegalEntity, navigating across all AssetOwnership links with that LegalEntity as the owner to the corresponding ownedAssets gives a collection of Assets that must be the same as the assetsOwned of the LegalEntity. The declaration of assetsOwned as ordered means that this collection is ordered in the same order as the assetsOwned of the LegalEntity. Similarly, if assetsOwned were non-unique, the collection could contain duplicate Assets.

Note that these semantics presume that values of cross features are exclusively due to the existence of links between them. However, it is still possible for the cross features to have values that do not correspond to any links, allowing the cross features to meet their multiplicity constraints without requiring corresponding links exist. That is, the declaration of cross features imposes necessary but not sufficient conditions on links that are instances of the association (see 7.3.2.1 ). To make these conditions also sufficient, requiring instances of the association to exist when cross feature values do, the association declaration can include the all keyword (see 7.3.2.2 ).

For example, as declared above, it is possible for a LegalEntity to have assetsOwned for which there are no instances of AssetOwnership linking the LegalEntity to the corresponding Assets. But with the declaration below, adding just an all keyword, a LegalEntity having an Asset as one of its assetsOwned is sufficient to require that an AssetOwnership link exists between that LegalEntity and that Asset, and, therefore, that the LegalEntity is also one of the owningEntities of the Asset.

assoc all AssetOwnership {
    end feature owner : LegalEntity crosses ownedAsset.owningEntities;
    end feature ownedAsset : Asset => owner.assetsOwned;
    feature valuationOnPurchase : MonetaryValue;
}

It is also possible to declare cross features directly in the declaration of the ends of an association, rather than nested in the related types of the association. Such owned cross features are declared between the end and feature keywords of the association end declarations (and, in this case, the feature keyword is required). These may be full feature declarations, including declared name and or short name, owned subsettings and redefinitions, etc., but without bodies and nested elements (see 7.3.4.2 on feature declaration).

assoc LegalAssetOwnership {
    end owningEntities[1..*] feature owner : LegalEntity;
    end assetsOwned[*] ordered feature ownedAsset : Asset;
    feature valuationOnPurchase : MonetaryValue;
}

Note. Owned cross features are in the namespace of the owning association ends, so their names are qualified by the name of the association ends, e,g., LegalAssetOwnership::owner::owningEntities.

For a binary association, an owned cross feature is implied to be featured by the type of the other association end, rather than its owning association end. Further, an association end with a cross feature has an implied cross subsetting relationship to the cross feature through the other end feature. This ensures owned cross features have the same semantics as cross features that are nested directly in the related types of the association. (For further details, see 8.4.4.5 on association semantics.)

Note. If an association end has an owned cross feature, then it may not have an explicit cross subsetting relationship declared to an unowned cross feature.

While owned cross features can have full feature declarations, it is often sufficient to just include the cross multiplicity, ordering, and/or uniqueness on one or more association ends.

assoc LegalAssetOwnership {
    end [1..*] feature owner : LegalEntity;
    end [*] ordered feature ownedAsset : Asset;
    feature valuationOnPurchase : MonetaryValue;
}

This specifies that every Asset must have one or more LegalEntities as its owners, and that every LegalEntity may have zero or more Assets as ownedAssets, which are ordered. Note that the association ends themselves, as participants of the association, still always have multiplicity 1..1, whether or not this is included in the declaration.

Cross features can also be used in associations with more than two ends. In general, the cross multiplicity, ordering, and uniqueness of an association end apply to the the collection of its values from each set of instances of the association that have the same (single) values for each of the other ends.

assoc AgreedAssetOwnership {
    end [*] feature owner : LegalEntity;
    end [*] ordered feature ownedAsset : Asset;
    end [0..1] feature agreement : OwnershipAgreement;
}

The cross multiplicity 0..1 for agreement requires that, for every pair of a LegalEntity and an Asset, at most one AgreedAssetOwnership instance may link that LegalEntity as its owner and Asset as its ownedAsset to an OwnershipAgreement as its agreement. Similarly, every pair of a LegalEntity as owner and an OwnershipAgreement as agreement may be linked to any number of Assets as ownedAsset, including none at all, as declared by the cross multiplicity of ownedAsset. This collection of linked Assests is ordered, as declared by the cross ordering of ownedAsset. The same applies to the cross multiplicity of owner. (For further details, see 8.4.4.5 on association semantics.)

If an association has a single superclassifier that is an association, it may inherit association ends from this superclassifier association. However, if it declares any owned association ends, then each of these must redefine an association end of the superclassifier association, in order, up to the number of association ends of the superclassifier. If no redefinition is given explicitly for an owned association end, then it is considered to implicitly redefine the association end at the same position, in order, of the superclassifier Association (including implicit defaults), if any. An implicitly or explicitly redefining association end may also further constrain the cross multiplicity (if any) of the superclassifier association ends that it redefines.

assoc SoleAssetOwnership specializes LegalAssetOwnership {
    end [1] feature owner; // Redefines LegalAssetOwnership::owner.
    // ownedAsset is inherited as an association end.
    // valuationOnPurchase is inherited as a non-end feature.
}

If an association has more than one superclassifier that is an association, then the association must declare a number of owned association ends at least equal to the maximum number of association ends of any of its superclassifier associations. Each of these owned association ends must then redefine the corresponding association end (if any) at the same position, in order, of each of the superclassifier associations.

If a feature has one or more association types, then it must subset the feature links from the Links library model (see 9.2.3 ). If any of the types are binary associations, then it must subset the feature binaryLinks from the Links library model (see 9.2.3 ). If necessary, the feature is given implicit subsettings to meet these requirements. (See also 7.4.6 on connectors as features typed by associations.)

Association structures are both associations and structures (see 7.4.4 on structures), classifying link objects, which are both links and objects (see 9.2.5.1 on objects). As objects, link objects can be created and destroyed, and their non-end features can change over time if they are variable and not constant (see also 7.3.4.2 ). However, the end features of a link object are always constant, their values cannot change over its lifetime.

An association structure is declared like a regular association (see 7.4.5.2 ), but using the keyword assoc struct. An association structure must directly or indirectly specialize the base associations structure LinkObject. If this is not the case due to the explicit owned superclassifications in its declaration, then it is implicitly given a default superclassification to either the association structure BinaryLinkObject (if it is a binary association structure) or the association structure LinkObject (otherwise), both of which are from the Objects library model (see 9.2.5 ). The same rules on association ends described in 7.4.5.2 for associations also apply to association structures. An association structure may specialize an association that is not an association structure, but all subclassifications of an association structure must be association structures.

struct LegalEntity {
    var feature assetsOwned [*] ordered : Asset;
}
struct Asset {
    var feature owningEntities [1..*] : LegalEntity;
}
assoc struct ExtendedAssetOwnership { // Specializes Objects::BinaryLinkObject by default.
    end feature owner : LegalEntity crosses ownedAsset.owningEntities;
    end feature ownedAsset : Asset crosses owner.assetsOwned;
    feature valuationOnPurchase : MonetaryValue;
    // The values of the feature "revaluations" may change over time.
    var feature revaluations[*] ordered : MonetaryValue;
}

The end features of an association structure may also be declared as constant features by placing the keyword const before the keyword end. Whether or not an end feature is declared as constant, its value cannot change for the lifetime of an instance of the owning association structure. However, a constant end feature may subset or redefine a variable feature, while a regular end feature cannot.

struct AssetOwnershipRecord {
    var feature owner : LegalEntity [1];
    var feature ownedAsset : Asset [1];
}
assoc struct AssetOwnershipRelationship specializes AssetOwnershipRecord {
    const end feature redefines owner;
    const end feature redefines ownedAsset;
}

If a feature has one or more types that are association structures, then it must subset the feature linkObjects from the Objects library model (see 9.2.5 ). If any of the types are binary association structures, then it must subset the feature binaryLinkObjects from the Objects library model (see 9.2.5 ). If necessary, the feature is given implicit subsettings to meet these requirements.

Metamodel references:

• Concrete syntax,  8.2.5.5
• Abstract syntax,  8.3.4.5
• Semantics,  8.4.4.6

Connectors are features that are typed by associations (see 7.4.5 ), having values that are links (see  9.2.3.1 ). Like an association, a connector has end features, known as its connector ends. Each connector end redefines an association end from each of the associations that type the connector and subsets a feature that becomes a related feature of the connector. Connectors typed by binary associations are called binary connectors.

A connector is also a relationship between its related features. For binary connectors, the two related features are identified as the source feature and the target feature, which might be the same. For connectors with more that two connector ends ("n-ary"), the first related feature is the source feature and all the remaining related features are target features.

Connectors can be thought of as "instance-specific" associations, because their values (which are links) are each limited to linking things identified via related features on the same instance of the connector's domain (or by things identified by that instance, recursively, see below). For example, an association could be used to model an engine driving wheels, and to type a connector in the car model. This connector specifies an engine driving wheels only in the same car, not in another car, as would be allowed with just the association.

Specifically, the values (links) of a connector are restricted to those that link things

1. classified by the types of its association ends, regardless of the domain of the connector
2. identified by its related features for the same instance of the domain of the connector (or by things identified by that instance, recursively).

For example, if the wheels in a car are taken to be part of its drive train, rather than part of the car directly, then the engine in each car will drive wheels identified by that car's drive train, rather than a feature of the car directly. This requires that each related feature of a connector have some featuring type of the connector as a direct or indirect featuring type (where a feature with no featuring type is treated as if the classifier Anything was its featuring type). In particular, this condition is satisfied if a connector has an owned type that either also directly owns the related features of the connector or from which the related features can be reached by chaining (see 7.3.4.6 ). Otherwise, explicit owned type featurings (see 7.3.4.8 ) should be used to ensure that the connector has a sufficiently general domain.

Binding connectors are binary connectors that require their source and target features to have the same values on each instance of their domain. They are typed by the library association SelfLink, which only links things in the modeled universe to themselves (see  9.2.3.1 ). To be meaningful, the declared co-domains of the related features of a binding connector must at least overlap. Since the interpretations of data types are disjoint from those of classes, this means that a feature typed by data types can only be bound to another feature typed by data types. In the determination of the equivalence of such features, indistinguishable data values are considered equivalent. The binding of features typed by classes to another feature typed by classes, on the other hand indicates that the same occurrences play the roles represented by each of the related features.

Successions are binary connectors requiring their source and target features to identify Occurrences that are ordered in time. They are typed by the library association HappensBefore (see  9.2.4.1 ), which links occurrences that happen completely separately in time, with the connector's source feature being the earlier occurrence and the target feature being the later occurrence.

A connector is declared as a feature (see  7.3.4.2 ) using the keyword connector. If no owned subsetting or owned redefinition is explicitly given for a connector, and none of its types are association structures, then the connector is implicitly given a default subsetting to the feature binaryLinks from the Links library model (see 9.2.3 ), if it is a binary connector, or to the feature links from the Links library model, otherwise. If at least one of the types of a connector is an association structure, then the default subsetting is instead to the feature binaryLinkObjects from the Objects library model (see 9.2.5 ), if it is a binary connector, or to the feature linkObjects from the Objects library model, otherwise.

In addition, a connector declaration includes connector end features that reference the features related by the connector. The connector ends may either be owned by the connector or inherited from the associations that type it or other connectors that it subsets (see also the description of association ends in 7.4.5 ). Each owned end of a connector redefines the end at the corresponding position (if any) of each of the associations or connectors it specializes. A connector with more than two ends can also have more ends than any of its supertypes. However, a connector that specializes a binary association or connector must itself be binary, with exactly two ends.

The related feature referenced by a connector end is specified using the keyword references or the equivalent symbol ::>. The number of connector ends is the same as the number of related features (including duplicates).

// Specializes Objects::BinaryLinkObject by default.
assoc struct Mounting {
    end feature mountingAxle : Axle;
    end feature mountedWheel : Wheel;
}
struct WheelAssembly { 
    composite feature axle[1] : Axle;
    composite feature wheels[2] : Wheel;

    // Subsets Objects::binaryLinkObjects by default.
    connector mount[2] : Mounting {
        end feature mountingAxle references axle;
        end feature mountedWheel references wheels;
    }
}

The references notation indicates that connector end features have reference subsetting relationships to the features related by the connector. Reference subsetting has the same semantics as regular subsetting (see 7.3.4.4 ) but is used to syntactically differentiate one of the owned subsettings of a feature. While reference subsetting is used primarily for connector ends in KerML, it can actually be specified as an owned subsetting in the declaration of any kind of feature, using the references or ::> symbol. A feature is allowed to have at most one owned subsetting that is a reference subsetting.

Instead of explicitly declaring connector ends in the body of the connector, they can be listed between parentheses, after the regular feature declaration part and before the body of the connector (if any).  In this case, the end declarations are limited to be of the form e references f or e ::> f, where e is the name of an association end and f is the qualified name of a related feature.

struct WheelAssembly {
    composite feature axle[1] : Axle;
    composite feature wheels[2] : Wheel;
    connector mount[2] : Mounting (
        mountingAxle ::> axle, 
        mountedWheel ::> wheels 
    );
}

The association end names can also be omitted, in which case the connector ends are matched in order to corresponding association ends.

struct WheelAssembly { 
    composite feature axle[1] : Axle;
    composite feature wheels[2] : Wheel;

    connector mount[2] : Mounting (axle, wheels);
}

By default, the connector ends of a connector are declared in the same order as the association ends of the types of the connector. However, if the connector has a single type, then the related features can be given in any order, with each related feature paired with an association end of the type using a notation of the form e references f or e ::> f, where e is the name of an association end and f is the qualified name of a related feature. In this case, the name of each association end must appear exactly once in the list of connector end declarations.

A special notation can be used for a binary connector, in which the source related feature is referenced after the keyword from, and the target related feature is referenced after the keyword to.

struct WheelAssembly { 
    composite feature axle[1] : Axle;
    composite feature wheels[2] : Wheel;

    connector mount : Mounting from axle to wheels;
}

If a binary connector declaration includes only the related features part, then the keyword from can be omitted.

struct WheelAssembly { 
    composite feature axle[1] : Axle;
    composite feature wheels[2] : Wheel;

    // Subsets Links::binaryLinks by default.
    connector axle to wheels;
}

If a binary connector has a single type, then the names of the association ends of the type can also be used in the declaration of the connector ends in the special notation for binary connectors. However, since the connector ends are always declared in order from source to target in this notation, the association end names given must match those from the type in the order they are declared for that type.

struct WheelAssembly {
    composite feature axle[1] : Axle;
    composite feature wheels[2] : Wheel;
    connector mount[2] : Mounting 
        from mountingAxle ::> axle 
          to mountedWheel ::> wheels;
}

Connector ends may have cross features, specified using cross subsetting, as for association ends (see 7.4.5.2 ). The cross feature for the connector end further constrains any inherited cross feature(s).

struct WheelAssembly {
    composite feature axle[1] : Axle {
        feature mountedWheels[2] : Wheel;
    }
    composite feature wheels[2] : Wheel;
    connector mount[2] : Mounting {
        end mountingAxle references axle;
        end mountedWheel references wheels crosses mountingAxle.mountedWheels;
    }
}

Connector ends may also have owned cross features. In the full notation for the end declaration, this is specified just as for an association end (see 7.4.5.2 ).

struct WheelAssembly {
    composite feature halfAxles[2] : Axle;
    composite feature wheels[2] : Wheel;
    // Connects each one of the halfAxles to a different one of the wheels.
    connector mount[2] : Mounting {
        end [1] feature mountingAxle references halfAxles;
        end [1] feature mountedWheel references wheels;
    }
}

In the shorthand notations, a cross multiplicity (but not ordering or non-uniqueness) can be given at the beginning of the end declaration.

struct WheelAssembly {
    composite feature halfAxles[2] : Axle;
    composite feature wheels[2] : Wheel;
    // Connects each one of the halfAxles to a different one of the wheels.
    connector mount[2] : Mounting from [1] halfAxles to [1] wheels;
}

Note that, if a connector is an owned feature of a type (as above), the context consistency condition for the related features of the connector (see  7.4.6.1 ) requires that these features also be directly or indirectly nested within the owning type. The feature chain dot notation (see  7.3.4.6 ) should be used when connecting so-called "deeply nested" features.

While the resolution of a feature chain is similar to a qualified name, the feature path contextualizes the resolution of the final feature. Thus, for example, while the qualified name axle::halfAxles statically resolves to Axle::halfAxles, in the Feature chain axle.halfAxles, halfAxles is understood to be specifically the feature as nested in axle.

struct Axle {
    composite feature halfAxles[2] : HalfAxle;
}
struct Wheel {
    composite feature hub : Hub[1];
    composite feature tire : Tire[1];
}
struct WheelAssembly {
    composite feature axle[1] : Axle;
    composite feature wheels[2] : Wheel;

    connector mount : Mounting from axle.halfAxles to wheels.hub;
}

A binding connector is declared as a feature (see  7.3.4.2 ) using the keyword binding. In addition, a binding connector declaration gives, after the keyword of, the qualified names of the two related features that are bound by the binding connector, separated by the symbol =, after the regular feature declaration part and before the body of the binding connector (if any). If no owned subsetting or owned redefinition is explicitly given, then the binding connector is implicitly given a default subsetting to the feature selfLinks from the Links library model (see 9.2.3 ). Note that, due to this default subsetting, if no type is explicitly given for a binding connector, then it will implicitly have the type SelfLink (the type of selfLinks).

struct Vehicle { 
    composite feature fuelTank {
        out var feature fuelFlowOut : Fuel;
    }

    composite feature engine {
        in var feature fuelFlowIn : Fuel;
    }

    // Subsets Links::selfLinks by default.
    binding fuelFlowBinding of fuelTank.fuelFlowOut = engine.fuelFlowIn;
}

If a binding connector declaration includes only the related features part, then the keyword of can be omitted.

struct Vehicle {
    composite feature fuelTank {
        out var feature fuelFlowOut : Fuel;
    }

    composite feature engine {
        in var feature fuelFlowIn : Fuel;
    }

    binding fuelTank.fuelFlowOut = engine.fuelFlowIn;
}

(See also 7.4.11 on the use of binding connectors with feature values.)

A succession is declared as a feature (see  7.3.4.2 ) using the keyword succession. In addition, the succession declaration gives the qualified name of the source feature after the keyword first and the qualified name of the target feature after the keyword then. If no owned subsetting or owned redefinition is explicitly given, then the succession is implicitly given a default subsetting to the feature happensBeforeLinks from the Occurrences library model (see 9.2.4 ). Note that, due to this default subsetting, if no type is explicitly given for a succession, then it will implicitly have the type HappensBefore (the type of happensBeforeLinks).

behavior TakePicture {
    composite step focus : Focus;
    composite step shoot : Shoot;
    succession controlFlow first focus then shoot;
}

If a succession declaration includes only the related features part, then the keyword first can be omitted.

behavior TakePicture {
    composite step focus : Focus;
    composite step shoot : Shoot;
    succession focus then shoot;
}

As for connector ends on regular connectors, constraining multiplicities can also be defined for the connector ends of successions.

behavior TakePicture {
    composite step focus[*] : Focus;
    composite step shoot[1] : Shoot;
    // A focus may be preceded by a previous focus.
    succession [0..1] focus then [0..1] focus;
    // A shoot must follow a focus.
    succession [1] focus then [0..1] shoot;
}

Metamodel references:

• Concrete syntax,  8.2.5.6
• Abstract syntax,  8.3.4.6
• Semantics,  8.4.4.7

Behaviors are classes that classify performances, which are kinds of occurrences that can be spread out in disconnected portions of space and time (see 9.2.6 ). The performance of behaviors can cause effects on other things, including their existence and relations, some of which might be accepted as input to or provided as output from the behavior.

Behaviors can have steps, which are features typed by behaviors, allowing the containing behavior to coordinate the performance of other behaviors. Steps can be ordered in time using succession connectors (see 7.4.6.4 ). They can also be connected by flows to model things flowing between the output of one step and the input of another. Steps can also nest other steps to augment or redefine steps inherited from their behavior types.

A behavior is declared as a classifier (see 7.3.3 ), using the keyword behavior. If no owned superclassing is explicitly given for the behavior, then it is implicitly given a default superclassing to the behavior Performance from the Performances library model (see 9.2.6 ).

Features declared in the body of a behavior with a non-null direction (see  7.3.4.2 ) are considered to be the owned parameters of the behavior. Features with direction in are input parameters, those with direction out are output parameters, and those with direction inout are both input and output parameters.

// Specializes Performances::Performance by default.
behavior TakePicture {
    in scene : Scene;
    out picture : Picture;
}

Parameters are ordered in the lexical order they are declared in the body of a behavior. They may appear at any location within the body.

If a behavior has owned subclassifications whose superclassifiers are behaviors, then each of the owned parameters of the subclassifier behavior must, in order, redefine the parameter at the same position of each of the superclassifier behaviors. The redefining parameters shall have the same direction as the redefined parameters.

behavior A { in a1; out a2; }
behavior B { in b1; out b2; }
behavior C specializes A, B {
    in c1 redefines a1, b1;
    out c2 redefines a2, b2;
}

If there is a single superclassifier behavior, then the subclassifier behavior can declare fewer owned parameters than the superclassifier behavior, inheriting any additional parameters from the superclassifier (which are considered to be ordered after any owned parameters). If there is more than one superclassifier behavior, then every parameter from every superclassifier must be redefined by an owned parameter of the subclassifier. If every superclassifier parameter is redefined, then the subclassifier behavior may also declare additional parameters, ordered after the redefining parameters. If no redefinitions are given explicitly for a parameter, then the parameter is implicitly given owned redefinitions of superclassifier parameters sufficient to meet the previously stated requirements.

behavior A1 :> A { in aa; } // aa redefines A::a1, A::a2 is inherited.
behavior B1 :> B { in b1; out b2; inout b3; } // Redefinitions are implicit.
behavior C1 :> A1, B1 { in c1; out c2; inout c3; }

Steps (see 7.4.7.3 ) declared in the body of a behavior are the owned steps of the containing behavior. A behavior can also inherit or redefine non-private steps from any superclassifier Behavior.

behavior Focus { in scene : Scene; out image : Image; }
behavior Shoot { in image : Image; out picture : Picture; }
behavior TakePicture { 
    in scene : Scene; 
    out picture : Picture;
    composite step focus : Focus;
    composite step shoot : Shoot;
}

Though the performance of a behavior takes place over time, the order in which its steps are declared has no implication for temporal ordering of the performance of those steps. Any restriction on temporal order, or any other connections between the steps, must be modeled explicitly.

behavior TakePicture {
    in scene : Scene;  
    out picture : Picture; 

    binding focus.scene = scene;
    composite step focus : Focus;
    succession focus then shoot;
    composite flow focus.image to shoot.image;
    composite step shoot : Shoot;
    binding picture = shoot.picture;
}

A step is declared as a feature (see  7.3.4.2 ) using the keyword step. If no owned subsetting or owned redefinition is explicitly given, then the step is implicitly given a default subsetting to the feature performances from the Performances library model (see 9.2.6 ).

As for a behavior, directed features declared in the body of a step are considered to be parameters of the step (see 7.4.7.2 ). If a step has owned specializations (including all feature typings, subsettings, and redefinitions), whose general type is a behavior or a step. then the rules for the redefinition of parameters of the behaviors and steps are the same as for the redefinition of the parameters of superclassifier behaviors by a subclassifier behavior (see 7.4.7.2 ).

step focus : Focus {
    // Parameters redefine parameters of Focus.
    in scene; 
    out image; 
}

// Parameters are inherited.
step refocus subsets focus; 

A step can also have a body, which may have steps in it. A step can inherit or redefine steps from its behavior types or any other steps it subsets.

step takePictureWithAutoFocus : TakePicture {
    in feature unfocusedScene redefines scene;
    step redefines focus : AutoFocus;
    out feature focusedPicture redefines picture;
}

Metamodel references:

• Concrete syntax,  8.2.5.7
• Abstract syntax,  8.3.4.7
• Semantics,  8.4.4.8

Functions are behaviors (see  7.4.7 ) with one out parameter designated as the result parameter. Functions classify evaluations (see 9.2.6.2.4 ), which are kinds of performances that produce results as values of the result parameter. Like all behaviors, functions can change things, often referred to as "side effects". A pure function is one that has no side effects and always produces the same results given the same input values, similarly to a function in the mathematical sense. The numerical functions in the Kernel Function Library (see 9.4 ), for example, are pure functions.

Expressions are steps (see 7.4.7 ) typed by only a single function, which means that their values are evaluations. An expression whose value is an evaluation with results is said to evaluate to those results. They can be steps in any behavior, but a function, in particular, can designate one of its expression steps as the result expression that gives the value of its result parameter. Expressions can have their own nested parameters, to augment or redefine those of their functions, including the result parameter. They can also own other expressions and designate a result expression, similarly to a function. (See also 7.4.9 for more on expressions).

Predicates are functions whose result is a single Boolean value (that is, true or false). A predicate determines whether the values of its input parameters meet particular conditions at the time of its evaluation, resulting in true if they do, and false otherwise. Predicates classify boolean evaluations, which are specialized evaluations giving a Boolean result (see 9.2.6.2.1 ).

Boolean expressions are expressions whose function is a predicate and, so, evaluate to a Boolean result. A boolean expression might, in general, evaluate to true at some times and false at other times. An invariant, though, is a boolean expression that must always evaluate to either true at all times or false at all times. By default, an invariant is asserted to always evaluate to true, while a negated invariant is asserted to always evaluate to false.

A function is declared as a behavior (see 7.4.7.2 ), using the keyword function. If no owned superclassing is explicitly given for a function, then it is implicitly given a default subclassification to the function Evaluation from the Performances library model (see 9.2.6 ). As for a behavior, any feature declared in the body of a function with an explicit direction is considered to be a parameter of the function. In addition, the result parameter of a function may be declared in its body by beginning the declaration with the keyword return (instead of a direction keyword).

// Specializes Performances::Evaluation by default.
function Velocity {
    in v_i : VelocityValue;
    in a : AccelerationValue;
    in dt : TimeValue;
    return v_f : VelocityValue;
}

If a function has owned subclassifications that are behaviors, then the rules for redefinition or inheritance of non-result parameters are the same as for a behavior (see 7.4.7.2 ). If some of the superclassifier behaviors are functions, then the result parameter of the subclassifier function must redefine the result parameters of the superclassifier functions. If, in this case, the result parameter of the subclassifier function has no owned redefinitions, then it is implicitly given redefinitions of the result parameter of each of the superclassifier functions.

abstract function Dynamics {
    in initialState : DynamicState;
    in time : TimeValue;
    return : DynamicState;
}
function VehicleDynamics specializes Dynamics {
    // Each parameter redefines the corresponding superclassifier parameter
    in initialState : VehicleState;
    in time : TimeValue;
    return : VehicleState;
}

The body of a function is like the body of a behavior (see 7.4.7.2 ), with the optional addition of the declaration of a result expression at the end. A result expression is always written using the Expression notation described in  7.4.9 , not using the Expression declaration notation from 7.4.8.3 . The result of the result expression is implicitly bound to the result parameter of the containing function.

function Average {
    in scores[1..*] : Rational;
    return : Rational;

    sum(scores) / size(scores)
}

Note. A result expression is written without a final semicolon.

The result of a function can also be explicitly bound, either using a binding connector (see 7.4.6.3 ) or a feature value on the result parameter declaration (see 7.4.11 ). In this case, the body of the function should not include a result expression.

function Average {
    in scores[1..*] : Rational;
    return : Rational = sum(scores) / size(scores);
}

An expression can be declared as a step (see 7.4.7.3 ) using the keyword expr (see also  7.4.9 for more traditional expression notation). If no owned subsetting or owned redefinition is explicitly given, then the expression is implicitly given a default subsetting to the feature evaluations from the Performances library model (see 9.2.6 ).

As for a step, directed features declared in the body of an expression are considered to be parameters of the expression (see 7.4.7.3 ). If an expression has owned specializations (including all feature typings, subsettings, and redefinitions) whose general type is a behavior (including a function) or a step (including an expression), then the rules for the redefinition of the parameters of those behaviors and steps are the same as for the redefinition of the parameters of superclassifier behaviors by a subclassifier function (see 7.4.8.2 ).

expr computation : ComputeDynamics {
    // Parameters redefined parameters of ComputeDynamics.
    in state;
    in dt;
    return result;
} 
expr vehicleComputation subsets computation {
    // Input parameters are inherited, result is redefined.
    return : VehicleState;
}

Like a function body, an expression body can also specify a result expression.

expr : VehicleDynamics { 
    in initialState;
    in time;
    return result;

    vehicleComputation(initialState, time)
}

Or the result can be explicitly bound.

expr : Dynamics { 
    in initialState;
    in time;
    return result : VehicleState =
        vehicleComputation(initialState, time);
}

A predicate is declared as a function (see 7.4.8 ), using the keyword predicate. If no owned subclassification is explicitly given for a predicate, then it is implicitly given a default subclassification to the predicate BooleanEvaluation from the Performances library model (see 9.2.6 ). If a predicate has owned subclassifications that are behaviors, then the rules for redefinition or inheritance of non-result parameters are the same as for a function (see 7.4.8.2 ). Since a predicate must always return a Boolean result, it is not necessary to explicitly declare a result parameter for it. However, if a result parameter is declared, then it must have type Boolean from the ScalarValues library model (see 9.3.2 ) and multiplicity 1..1 (see 7.4.12 ).

predicate isAssembled {
    in assembly : Assembly;
    in subassemblies[*] : Assembly;
}

The body of a predicate is the same as a function body (see 7.4.8 ). If a result expression is included, then it must have a Boolean result.

predicate isFull {
    in tank : FuelTank;
    tank.fuelLevel == tank.maxFuelLevel 
}

A boolean expression is declared as an expression (see 7.4.8.3 ), using the keyword bool. If no owned subsetting or owned redefinition is explicitly given, then the boolean expression is implicitly given a default subsetting to the feature booleanEvaluations from the Performances library model (see 9.2.6 ).

As for an expression, directed features declared in the body of a boolean expression are considered to be parameters of the boolean expression (see 7.4.8.3 ). If a boolean expression has owned specializations (including all feature typings, subsettings, and redefinitions) whose general type is a behavior or step, then the rules for the redefinition of the parameters of those behaviors and steps are the same as for a regular expression declaration (see 7.4.8.3 ). The requirements on, and default for, the result parameter of a boolean expression are the same as for a predicate (see 7.4.8.4 ).

// All input parameters are inherited.
bool assemblyChecks[*] : isAssembled;

Like a predicate body (see 7.4.8.4 ), a boolean expression body can specify a Boolean result expression.

class FuelTank {
    feature fuelLevel : Real;
    feature readonly maxFuelLevel : Real;
    bool isFull { fuelLevel == maxFuelLevel }
}

An invariant is declared like any other boolean expression, except using the keyword inv instead of bool, and, additionally, this keyword may be optionally followed by one of the keywords true or false, to indicate whether the invariant is asserted to be true or false (i.e., is negated). The default is true.

class FuelTank {
    feature fuelLevel : Real;
    feature readonly maxFuelLevel : Real;
    // The invariant is asserted true by default. 
    inv { fuelLevel >= 0 & fuelLevel <= maxFuelLevel }
    // The invariant is explicitly asserted false, that is, it is negated.
    inv false { fuelLevel > maxFuelLevel }
}

Metamodel references:

• Concrete syntax,  8.2.5.8
• Abstract syntax,  8.3.4.8
• Semantics,  8.4.4.9

As described in  7.4.8 , expressions are steps typed by functions, and 7.4.8.3 covers the general notation for declaring an expression as a step. However, expressions are commonly organized into tree structures, with expressions as the nodes, and the input parameters of each expression bound to the result of each of its child expressions. KerML includes extensive textual notation for constructing expression trees, including traditional operator notations for functions in the Kernel Model Library (see Clause 9 ).

These expression notations map entirely to an abstract syntax involving just a few specialized kinds of expressions:

• The non-leaf nodes of an expression tree are invocation expressions, a kind of expression that specifies its input values as the results of other expressions (its argument expressions), one for each of the input parameters of its invoked function.
• The edges of the tree are binding connectors between the input parameters of an invocation expression (redefining those of its function) and the results of its argument expressions.
• The leaf nodes are these kinds of expressions:
  • Feature reference expressions evaluate to values of a referenced feature that is not part of the expression tree.
  • Literal expressions evaluate to the literal value of one of the primitive data types from the ScalarValues model library (see 9.3.2 ).
  • Null expressions evaluate to the empty set.

An expression can also be the referent of a feature reference expression in an expression tree, as above. This enables the evaluation of the referent expression to be taken as the value of the argument of an invocation, rather than passing the value of the result of the evaluation. As a shorthand for doing this, the concrete syntax for an expression body (as described in 7.4.8.3 ) can be used as a leaf node in the expression syntax tree.

A model-level evaluable expression is an expression that refers to metadata, which is data about model elements, rather than the things being modeled. Model-level evaluable expressions can give values to the features of metadata (see 7.4.13 ) and be used as element filtering conditions in packages (see 7.4.14 ). The expressiveness of model-level evaluable expressions is restricted to support this:

• All null expressions, literal expressions and feature reference expressions are model-level evaluable.
• An invocation expression is model-level evaluable if and only if it meets the following conditions:

1. All its argument expressions are model-level evaluable.
2. It invokes a function that is listed as being model-level evaluable in Table 5 (in 8.2.5.8.1 ) or Table 7 (in 8.2.5.8.2 ).

Operator expression notation provides a shorthand for invocation expressions that invoke a library function represented as an operator symbol. ( Table 5 in  8.2.5.8.1 shows the mapping from operator symbols to the functions they represent from the Kernel Model Library.) An operator expression contains subexpressions called its operands that generally correspond to the argument expressions of the invocation expression, except in the case of operators representing control functions, in which case the evaluation of certain operands is as determined by the function.

Operator expressions include the following:

• Conditional expressions. The conditional test operator if is followed by three operands, with the symbol ? after the first operand and the keyword else after the second operand. A conditional expression evaluates to the value of its second or third operand, depending on whether the result of its first operand is true or false. Note that only one of the second or third operand is actually evaluated.

  if x >= 0? x else -x
  

• Binary operator expressions. A binary operator is one that has two operands. The binary operators include numerical operators (+, -, *, /, %, ^, **), logical operators (&, |, xor), comparison operators (==, !=, <, >, <=, >=, ===, !==), and the range construction operator (..). In general, both operands become arguments of the invocation expression, with their results being passed to the invocation of the function represented by the operator. However, the null-coalescing (??), conditional and (and), conditional or (or) and implication (implies) operators all correspond to control functions in which their second operand is only evaluated depending on a certain condition of the value of their first operand (whether it is null, true, false, or true, respectively).

  x + y
  list#(i) ?? default
  i > 0 and sensor#(i) != null
  sensor == null or sensor.reading > 0
  

  The operators == and != apply to operands that have single values, testing whether they are equal or unequal, respectively. They also evaluate to true or false, respectively, if their operands are both null (no values). The operators === and !== apply specifically to values that are occurrences (see 9.2.4 ). They test whether two occurrences are portions (in space and/or time) of the same life occurrence. Informally, these operators test whether or not two occurrences have the same "identity". For data values (values that are not occurrences), === and !== are the same as == and !=.

  currentPortion == tripPortion  // True for same trip portions
  currentPortion === tripPortion // True for any two portions of same trip
  

• Unary operator expressions. A unary operator is one that has a single operand. The result of evaluating the operand is passed to the invocation of the Function represented by the operator. The unary operators include the numerical operators + and - and the logical operator not.

  -x
  not isOutOfRange(sensor)
  not completed
  

• Classification expressions. The classification operators are syntactically similar to binary operators, but, instead of an expression as their second operand, they take a type name. The classification operators istype and hastype test whether all of the values of their first operand is classified by the named type (either including or not including subtypes, respectively). The @ operator is similar to istype, but tests whether at least one of the values of its first operand is classified by the named type. Note that this means that istype and hastype evaluate to true on a null (empty list) value, while @ evaluates to false.

  sensors istype ThermalSensor // Are all sensors ThermalSensors?
  sensors @ ThermalSensor // Is any sensor a ThermalSensor?
  person hastype Administrator
  

  The classification operator as, known as the cast operator, performs an isType test of whether each of the values of its first operand is classified by the named type, and then it selects only those values that pass the test to include in its result. The result values of such a cast expression (if any) are always guaranteed to be instances of the named type.

  sensors as ThermalSensor
  person as Administrator
  

  The classification operators may also be used without a first operand, in which case the first operand is implicitly Anything::self (see 9.2.2.2.1 ). This is useful, in particular, when used as a test within an element filter condition expression (see 7.4.14 ).

  istype ThermalSensor
  @ThermalSensor
  hastype Administrator
  as Supervisor
  

• Metaclassification expressions. The metaclassification operators @@ and meta take the qualified name of any kind of element as their first operand and a metaclass (see  7.4.13 ) as their second operand. They are shorthands for classification expressions with the operators @ and as, respectively, and a metadata access expression (see  7.4.9.4 ) as their first operand. As such, @@ tests whether any metadata associated with an element are classified by the given metaclass, while meta filters the metadata associated with an element and evaluates to those that are classified by the given metaclass.

  // Shorthand for designModel.metadata @ ApprovalAnnotation
  designModel @@ ApprovalAnnotation
  
  // Shorthand for sensors.metadata as KerML::Feature
  sensors meta KerML::Feature
  
  // Evaluates to the string "sensors".
  (sensors meta KerML::Feature).name
  

• Extent expressions. The extent operator all is syntactically similar to a unary operator, but, instead of an expression as its operand, it takes a type name. An extent expression evaluates to a sequence of all instances of the named type.

  all Sensor

In an operator expression containing nested operator expressions, the nested expressions are implicitly grouped according to the precedence of the operators involved, as given in Table 6 (in 8.2.5.8.1 ). Operator expressions with higher precedence operators are grouped more tightly than those with lower precedence operators. In addition, all binary operators other than exponentiation group to the left. The exponentiation operators (^ and **) group to the right. For example, the operator expression:

-w + x * y * z + a ^ b ^ c

is considered equivalent to:

( (-w) + ( (x * y) * z ) ) + ( a ^ (b ^ c) )

Primary expression notation provides additional shorthands for certain kinds of invocation expressions.For those cases in which the invoked function is represented by an operator symbol, the symbol is mapped to the appropriate library function as given in Table 7 (in 8.2.5.8.2 ).

Primary expressions include the following:

• Index expression. An index expression specifies the invocation of the indexing function '#' from the BaseFunctions library model (see 9.4.2 ). The default behavior for this function is given by the specialization SequenceFunctions::'#', for which the first operand is expected to evaluate to a sequence of values, and the second operand is expected to evaluate to an index into that sequence. Default indexing is from 1 using Natural numbers. Note that parentheses are required around the second operand.

  sensors#(activeSensorIndex)
  

  However, the behavior of the '#' operator is specialized for the OrderedCollection (see 9.3.3.2.7 ) and Array (see 9.3.3.2.1 ) data types from the Collections library model. In this case, the first operand must be a single value of one of these data types. For an Array, the second operand is a sequence of indexes whose size is the rank of the Array (i.e., the number of dimensions of the Array).

  detectorArray#(n, m)
  

• Sequence expression. A sequence expression consists of a list of one or more expressions separated by comma (,) symbols, optionally terminated by a final comma, all surrounded by parentheses (...). Such an expression specifies sequential invocations of the sequence concatenation function ',' from the BaseFunctions library model (see 9.4.2 ). The default behavior for this Function is given by the specialization SequenceFunctions::',', which concatenates the sequence of values resulting from evaluating its two arguments. With this behavior, a sequence expression concatenates, in order, the results of evaluating all the listed expressions.

  (temperatureSensor, windSensor, precipitationSensor)
  ( 1, 3, 5, 7, 11, 13, )
  

  A sequence expression with a single constituent expression simply evaluates to the value of the contained expression, as would be expected for a parenthesized expression. The empty sequence () is not actually a sequence expression, but, rather, an alternative notation for a null expression (see 7.4.9.4 ).

  (highValue + lowValue) / 2
  

  Sequences of values are not themselves values. Therefore, sequences are "flat", with no element of a sequence itself being a sequence. For example, ((1, 2, 3), 4), (1, (2, 3), 4) and (1, null, (2, 3, 4)) all evaluate to the same sequence of values as (1, 2, 3, 4). To model nested collection values, use the data types from the Collections library model (see 9.3.3 ).
• Feature chain expression. A feature chain expression consists of a primary expression and a feature qualified name or a feature chain ( 7.3.4.6 ), separated by a dot (.) symbol. The referenced feature is evaluated in the context of each of the result values of the primary expression, in order. The resulting feature values are then collected into a sequence in order of evaluation. The qualified name for the referent feature is resolved using the result parameter of the primary expression as the context namespace (see 8.2.3.5 ), but considering only visible memberships.

  // The primary expression is "getPlatform(id)".
  // The feature chain is "sensors.isActive".
  // Results in a sequence of Boolean values, 
  // one for each platform sensor.
  getPlatform(id).sensors.isActive   
  

  To avoid ambiguity, the primary expression of a feature chain expression cannot be itself a feature chain expression. To read a list of features sequentially, rather than in a single evaluation, delimit nested feature chain expressions using parentheses.

  // First evaluate "getPlaform(id).sensors",
  // then evaluate ".isActive" on the result of that.
  (getPlatform(id).sensors).isActive
  

• Collect expression. A collect expression consists of a primary expression and an expression body (see  7.4.9.4 ) separated by a dot (.) symbol. The expression body must have a single input parameter. The expression body is evaluated on each of the result values from the primary expression, in order, and each of the results are collected into a sequence in order of evaluation (that is, a collect expression is a shorthand for invoking the ControlFunctions::collect function).

  sensors.{in s: Sensor; s.reading}  // results in a sequence of 
                                     // readings of each of the sensors
  

• Select expression. A select expression consists of a primary expression and an expression body (see  7.4.9.4 ) separated by a dot-question-mark (.?) symbol. The expression body must have a single input parameter and a Boolean result. The expression body is evaluated on each of the result values from the primary expression, in order, and those for which the expression body evaluates to true are selected for inclusion in the result of the select expression (that is, a select expression is a shorthand for invoking the ControlFunctions::select function).

  sensors.?{in s: Sensor; s.isActive}  // results in the subsequence of 
                                       // sensors that are active
  

• Function operation expression. A function operation expression is a special syntax for an invocation expression in which the first argument is given before the arrow (->) symbol, which is followed by the name of the function to be invoked and an argument list for any remaining arguments (see  7.4.9.4 ). This is useful for chaining invocations in an effective data flow.

  sensors -> selectSensorsOver(limit) -> computeCriticalValue()
  

  If the invoked function has exactly two input parameters, and the second input parameter is an expression, then an expression body (see  7.4.9.4 ) can be used as the argument for the second argument without surrounding parentheses. The argument expression body should declare parameters consistent with those on the parameter expression (if any). This is particularly useful when invoking functions from the ControlFunctions library model (see 9.4.17 ).

  sensors -> select {in s: Sensor; s::isActive}
  members -> reject {in member: Member; not member->isInGoodStanding()}
  factors -> reduce {in x: Real; in y: Real; x * y}
  

  If the argument expression is simply the direct invocation of another function, then the argument expression may be specified using simply the name of the invoked function.

  factors -> reduce RealFunctions::'*'
  

Base expression notation includes representations for literal expressions, null expressions, invocation expressions, feature reference expressions (including using expression bodies as base expressions).

• Literal expressions are described in 7.4.9.5 .
• A null expression is notated by the keyword null. A null expression always evaluates to a result of "no values", which is equivalent to the empty sequence ().
• An invocation expression can be directly represented by giving the qualified name for the function to be invoked followed by a list of argument expressions, surrounded by parentheses () and separated by commas. The parentheses must be included, even if the argument list is empty.

  IntegerFunctions::'+'(i, j)
  isInGoodStanding(member#(n))
  AddMember(org, member)

  The arguments are matched to the input parameters of the given function in order. Alternatively, the arguments may be matched to parameters by name, using the form paramName = argExpression, in which case they may be given in any order. Note that, if the named argument notation is used, it must be used for all arguments.

  AddMember(newMember = member, organization = org)

  If the qualified name given for an invocation expression resolves to an expression instead of a function, then the invocation expression is considered to subset the named expression, meaning that, effectively, the invocation is taken to be for the function of the named expression, as specialized by that expression.

  function UnaryFunction {in x : Anything; return: Anything;}
  function apply {
      in expr fn : UnaryFunction;
      in value : Anything;
  
      // Invokes UnaryFunction as specified by parameter fn.
      return : Anything = fn(value); 
  }

  It is also possible to specify an expression to be invoked using a feature chain (see 7.3.4.6 ).

  class Stats {
      feature vales[1..*] : Real;
      expr avg { sum(values)/size(values) }
  }
  feature myStats : States {
      redefines feature values = (1.0, 2.0, 3.0);
  }
  feature myAvg = myStats.avg();

  If the qualified name given for an invocation expression resolves to a behavior that is not a function (or a feature typed by a behavior that is not a function), then that behavior is performed and the result of the expression is the performance itself. This allows, for example, access to the values of the out parameters of the behavior computed during its performance.

  behavior RefineImage {
      in image : Image;
      out refinedImage : Image;
      out logMessages : String[*];
  }
  feature run1 = RefineImage(image1);
  feature refinedImage1 = run1.refinedImage;
  feature log1 = run1.logMessages;

• A constructor expression is represented by the keyword new followed by the qualified name of a type to be instantiated invoked followed by a parenthesized list of argument expressions, similarly to an invocation expression. The result of the expression is a new instance of the target type, with the results of the argument expressions bound to the public features of the type, in order or by name.

  class Member {
      feature firstName : String;
      feature lastName : String;
      feature memberNumber : Integer;
      feature sponsor : Member[0..1];
  }
  feature thisMember = new Member("Jane", "Doe", 1234, null);
  feature nextMember = new Member(
      firstName = "John", lastName = "Doe", sponsor = thisMember,
      memberNumber = thisMember.memberNumber + 1);

• A feature reference expression is represented simply by the qualified name of the feature being referenced.

  member
  spacecraft::mainAssembly::sensors
  sensor::isActive

  Note that the referenced feature may be an expression. The notation for a reference to an expression is distinguished from the notation for an invocation by not having following parentheses.

  expr addOne : UnaryFunction {
      if x istype Integer? (x as Integer) + 1 else 0
  }
  feature two = apply(addOne, 1); // "addOne" is a reference to expr addOne

  Rather than declaring a named expression in order to pass it as an argument, an expression body may be used directly as a base expression. In this case, any parameters must be declared as features with direction within the expression body (see 7.4.8.3 ). Such body expressions are particularly useful when used for the second argument of a function operation expression (see 7.4.9.3 ).

  feature two = 
      apply({in x; if x istype Integer? (x as Integer) + 1 else 0}, 1);
  feature incrementedValues = 
      values -> collect {in x: Number; x + 1};
  

• A metadata access expression is represented by suffixing the qualified name of any kind of element with the notation .metadata. This is a reflective expression that evaluates to the sequence of metadata features associated with the named element in the model itself, as instances of their respective metaclasses (see 7.4.13 on metadata and metaclasses). In addition, the last value in the sequence is an instance of the metaclass for the named element from the KerML reflective abstract syntax model (see 9.2.17 ), representing its instantiation as a model element.

  metaclass SecurityAnnotation;
  class SecureSystem {
      metadata SecurityAnnotation;
  }
  
  // Two values: an instance of SecurityAnnotation 
  // and an instance of type KerML::Class.
  feature sysMetadata = SecureSystem.metadata;
  

A literal expression is represented by giving a lexical literal for the value of the expression.

• A literal Boolean is represented by either of the keywords true or false.
• A literal string is represented by a lexical string value surrounded by double quotes "…" as specified in 8.2.2.5 .

  "This is a string literal."

• A literal integer is represented by a lexical decimal value as specified in 8.2.2.4 . Note that notation is only provided for non-negative integers (i.e., natural numbers). Negative integers can be represented by applying the unary negation operator - (see 7.4.9.2 ) to an unsigned decimal literal.

  0
  1234

• A literal rational is represented with a syntax constructed from lexical decimal values and exponential values (see 8.2.2.4 ). The full rational number notation allows for a literal with a decimal point, with or without an exponential part, as well as an exponential value without a decimal point.

  3.14
  .5
  2.5E-10
  1E+3

• A literal infinity is represented by the symbol *.

Metamodel references:

• Concrete syntax,  8.2.5.9
• Abstract syntax,  8.3.4.9
• Semantics,  8.4.4.10

Interactions are behaviors that are also associations (see 7.4.7 and 7.4.5 , respectively), classifying performances that are also links between occurrences (see 9.2.3 through 9.2.6 ). They specify how the linked participants affect each other and collaborate.

Transfers are interactions between two participants that carry payload values from one occurrence to another, with payload values optionally identified by output and input features of the source and target occurrence, respectively (see 9.2.7 ).

Flows are steps that are also binary connectors (see 7.4.7 and 7.4.6 , respectively), with values that are transfers. A flow optionally ensures that a payload is transferred from an output feature of the connected source feature to an input feature of the target feature. Succession flows are flows that are also successions (see 7.4.6 ). They identify transfers that happen after their source (that is, after the end of the occurrence where the payload comes from) and before their target (that is, before the start of the occurrence where the payload goes to).

An interaction is declared as a behavior (see 7.4.7 ), using the keyword interaction. If no owned subclassification is explicitly given for the interaction, then it is implicitly given default subclassifications to both the behavior Performance from the Performances library model (see 9.2.6 ) and the association BinaryLink or the association Link from the Links library model (see 9.2.3 ), depending on whether it is a binary interaction or not.

As a kind of behavior, if the interaction has owned subclassifications whose superclasses are behaviors, then the rules related to their parameters are the same as for any subclassifier behavior (see 7.4.7 ). As a kind of association, the body of an interaction must declare at least two association ends. If the interaction has owned subclassifications whose superclassifiers are associations, the rules related to their association ends are the same as for any association that is a subclassifier (see 7.4.5 ).

interaction Authorization {
    end feature client[*] : Computer;
    end feature server[*] : Computer;
    composite step login;
    composite step authorize;
    composite succession login then authorize;
}

A flow declaration is syntactically similar to a binary connector declaration (see 7.4.6 ), using the keyword flow, or succession flow for a succession flow. If no owned subsetting or owned redefinition is explicitly given, then the flow is implicitly given a default subsetting to the flow transfers from the Transfers model library (see 9.2.7 ), or to the succession flow transfersBefore, if a succession flow is being declared. If a flow has owned specializations (including all feature typings, subsettings, and redefinitions) whose general type is a behavior or a step, then the rules for the redefinition of the parameters of those behaviors and steps are the same as for the redefinition of the parameters of general behavior or step by a specializing step (see 7.4.7.3 ).

Unlike a regular binary connector declaration, though, a flow declaration does not directly specify the related features for the flow. Instead, the declaration gives the source output feature for the transfer after the keyword from and the target input Feature for the transfer after the keyword to. The related features are then determined as the owning features of the features given in the flow declaration. It is these related features that are constrained to have a common context with the flow (see 7.4.6 ), not the features actually given in the declaration.